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
moot.
http://groups-beta.google.com/group/perl.perl6.internals/msg/18b86bff49cac5a0?dmode=source
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
hit.
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.
