[Chicago-talk] Speaking of threading
lembark at wrkhors.com
Wed Dec 10 13:07:23 CST 2003
-- Greg Fast <gdf at speakeasy.net>
> On Tue, 09 Dec 2003 13:29:48 -0600, Steven Lembark <lembark at wrkhors.com>
>> -- 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 one thing I still have not seen a good solution for, mainly
an issue with thread-pool situations, is how to kill one thread.
I don't know if anyone has found a good way to attach some kind
of secondary data outside the signal that will allow the signal
handler to zap just one thread.
> 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.
I spent 3+ months at one site converting the 15_000 (no typo)
java classes they had created into HTML so that we could track
the bottlenecks. One of the main ones was that they had picked
a java hash as the base data type for their "container" class.
Catch: java hashes have a built-in semaphore (at least they did
w/ Sun's implementation back then). Net result was that even if
they didn't have multiple threads tickling the data struct's
they still had to stop and check the semaphore.
Somehow, I have to believe that the nice folks at Sun could've
just developed a threading modle that encapsulated the thread
and saved you the trouble and however many more people the
> 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.
It has varied, considerably, for code developed on
windog and run on a "universal" platform such as java.
In most cases the code does not work becuase of differences
in the java engines used on the differing platforms -- Solaris,
NT/W32, AIX, and OpenVMS have java runtime engins and lib's
that are incompatable in various ways.
There are any number of perl-isms that did not port well to
W32, many of which have been solved over time. The main
difference I've seen as a consultant cleaning up things is
that many people took Sun's sales pitch about write once a
bit too seriously and were unprepared when it didn't run
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 888 359 3508
More information about the Chicago-talk