[Chicago-talk] Speaking of threading

Steven Lembark 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>
> 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 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
mistakes.

> 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
everywhere.



--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 888 359 3508



More information about the Chicago-talk mailing list