Sharing data between the threads/interpreters is implemented by tieing the two copies of the variables to be shared and each time a STORE is performed in one thread, the same STORE has too be performed on the copy of that var held on every other threads dataspace.
Hmmm.... is that true? My impression was (and that's the way I've implemented it in Thread::Tie) is that each STORE actually stores the value in a hidden background thread, and each FETCH obtains the current value from the background thread. I don't think each STORE is actually cascading through all of the threads. Not until they try to fetch the shared value, anyway.
If 2 threads need to share a scalar, but the program has 10 other threads, then each write to the shared scalar requires the update of all 12 copies of that scalar. There is no way to indicate that you only need to share it between threads x & y.
That's true. But there is some implicit grouping. You can only create newly shared variables for the current thread and any thread that is started from the current thread. This is actually a pity, as that precludes you to start a "bare" (minimal number of Perl modules loaded, or with exactly the modules that _you_ want) thread at compile time, from which you could start other threads.
With ithreads, there can be no shared references, so no shared objects and no shared compound data structures
Actually, you can bless a reference to a shared variable, but you can't share a blessed object (the sharing will let you lose the content of the object). I think shared compound data structures _are_ possible, but very tricky to get right (because the CLONE sub is called as a package method, rather than as an object method: see Thread::Bless for an attempt at getting around this).
> While these can be separated its not efficient. Please note that Parrotis a register-based VM. Switching state is *not* switching a stack-pointer and a PC thingy like in stack-based VMs. > ... The runtime costs of duplicating all > shared data between interpreters, tying all shared variables, added to > the cost of locking, throw away almost all of the benefit of using > threads. No, shared resources are not duplicated, nor tied. The locking of course> remains, but that's it. The issues above are what make p5 ithreads almost unusable.
For more about this, see my article on Perl Monks:
http://www.perlmonks.org/index.pl?node_id=288022
And the reaction from those wh have tried to make use of ithreads under p5 are all too aware that replicating them for Parrot would be ..... [phrase deleted as too emotionally charged:)]
What can I say? ;-)
Liz
