[Chicago-talk] Speaking of threading

[Greg Fast]

On Tue, 09 Dec 2003 13:29:48 -0600, Steven Lembark <lembark at wrkhors.com> wrote:
> -- Greg Fast <gdf at speakeasy.net>
> > Python, Ruby, etc), the advantages of threading over fork() are pretty
> > self-evident.
> 
> Yeah: overwritten varibales, semaphonre and mutex lock waits :-)

You have to deal with shared resource contention in a multiprocessing
system too, you just don't get help from the language.  "Hey, why
does my temp file keep getting truncated?"


> The main problem for
> most cases is lack of private data (which perl-5.8 solves
> by privatizing lexicals).

In Java (say), the typical practice is to extend the Thread class (or,
equivalently for this situation, implement Runnable), and create a new
object encapsulating each thread of execution.  Thus, private
per-thread data.  Having multiple threads call methods on a shared
object is an issue for synchronization, but I personally think
explicitly marked potential bottlenecks are easier to deal with than
implicitly entwined resource conflicts.


> > [2] By "portably", I mean "given two ports of language X, the same
> > code will run under both".  fork() is not "portable" (though it's
> > *mostly* portable, these days).
> 
> Neither are threads, depending on your threading model
> and what's supported on the configuration (e.g., cluster).

If I have a Java (or Python, or Ruby) program using threads, and I run
it on random platform X, I know it will work because the
implementation is hidden by standard language constructs.  If I have a
Perl prog using fork() it may not work, depending on whether random
platform X's implementation of Perl implements fork() (as win32 Perls
didn't, for years).  Not a pro or con, necessarily, just a definition.

Anyway, YMMV I guess.

--
Greg Fast
http://cken.chi.groogroo.com/~gdf/