[Chicago-talk] Speaking of threading
Greg Fast
gdf at speakeasy.net
Wed Dec 10 11:13:41 CST 2003
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/
More information about the Chicago-talk
mailing list