On Sat, 23 Apr 2005 21:00:11 -0700, [EMAIL PROTECTED] (Larry Wall) wrote:
> On Sun, Apr 24, 2005 at 03:37:23AM +0000, Nigel Sandever wrote:
> : On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) 
> : > 
> : > Oh well.  At least the same code can be salvaged to make iThreads
> : 
> : Please. No iThreads behaviour in Perl 6. 
> : 
> : Nobody uses them and whilst stable, the implementation is broken in so many 
> : 
> : But worse, the underlying semantics are completely and utterly wrong.
> Are you confusing iThreads with pThreads?  Or are you recommending we
> go back to the pThreads fiasco?

I certainly am not advocating a shared-by-default, or everything-shared model.

> From what I've read, the trend in most modern implementations of
> concurrency is away from shared state by default, essentially because
> shared memory simply doesn't scale up well enough in hardware, and
> coordinating shared state is not terribly efficient without shared
> memory.  If you are claiming that modern computer scientists are
> completely and utterly wrong in moving that direction, well, that's
> your privilege.  But you should be prepared for a little pushback
> on that subject, especially as you are merely badmouthing something
> without goodmouthing something else in it's place.

When I said "iThreads", I was referring to the only defenition I can find for 
iThreads, the Perl 5.8.x implementation. 

The "broken underlying semantics" are

1) The fork-like, "duplicate-everything-in-the-process-at-the-point-of-spawn".

This makes spawning a thread heavier than starting a process in many cases. It 
makes using (the p5 implementation of) iThreads an exercise in frustration 
trying to avoid the semantics it imposes.

2) The shared-memory is really multiple-copies-with-ties.

This removes 90% of the benefits of shared-memory, whilst doing nothing to make 
it easier to use. The user is still responsible for locking and 
but looses the ability to use either ties or object-semantics to encapsulate 
That forces every programmer to re-invent the techniques in every program as it 
is nearly impossible to write clean, effcient apis and put them into modules.

The duplication and tied-updates makes using shared memory so slow and clumsy, 
that it can be quicker to freeze/transmit-via-socket/thaw shared data between 
processes, than to share a piece of memory within a process.

3) Using the low-level pthreads api as the basis for the user view of threading.

This precludes the use of native thread features on any platform that has 
extended or better api, and forces the programmer to deal with the ultra-low-
level at which that API is defined without any of the control that he would 
if using it directly.

> Larry


Reply via email to