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.