On Sun, 2005-04-24 at 07:51 +0000, Nigel Sandever wrote:
> On Sat, 23 Apr 2005 21:00:11 -0700, [EMAIL PROTECTED] (Larry Wall) wrote:

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

Keep in mind that, these considerations aside, Parrot is implementing an
interpreter-per-thread model, so much of the debate for P6-on-Parrot is

        We'd decided that each thread has its own interpreter. Parrot
        doesn't get any lighter-weight than an interpreter, since trying
        to have multiple threads of control share an interpreter seems
        to be a good way to die a horrible death.
        -Dan Sugalski / 14 Apr 2005

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

Keep in mind that for Parrot, this won't be as big a deal. It will mean
that thread-creation will probably stomp all over the gains in
performance that the JIT gives you, but that irons itself out over time
(so again, long-lived threads are more efficient than short-lived ones).

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

Again, given Parrot this is not as big a deal. "tying" is just a matter
of adding vtable entries, and one layer of PMC indirection is not a huge

It does mean that shared access to low-level types (int, str, etc) will
preclude their being implemented as truly low-level types (i.e. they
will be PMCs, not int, str, etc. in Parrot). However, I can't really
imagine a sane shared-access scheme that would not take this hit.

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

Again, I think letting Parrot (or whatever underlies your given P6
implementation) do a lot of this work for you allows you, once again, to
do the right thing.

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

Again, I doubt you'll see the same behavior on top of Parrot. Then
again, this is arm-waving, and I don't know what state threading is in
in the Parrot world.

> 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 
> have 
> if using it directly.

Hopefully we can abstract that away a bit, and presumably you could
always write a Parrot module to provide some native semantics for
threading, but that would require some deep Parrot spelunking.

Reply via email to