Parrot bytecode reentrancy
Nigel Sandever
That is, if I want to have two instances of a class in each of two threads, will
the bytecode for the class need to be loaded twice?
Also, will it be possible to pass objects (handles/references) between threads?
Thanks njs.
MrJoltCola
>Is Parrot bytecode reentrant?
Yes.
>That is, if I want to have two instances of a class in each of two
>threads, will
>the bytecode for the class need to be loaded twice?
No, just once.
>Also, will it be possible to pass objects (handles/references) between
>threads?
Yes, otherwise threads are no more useful than processes.
-Melvin
Nigel Sandever
wrote:
When a sub that closes over a variable
my $closure = 0;
sub do_something {
return $closure++:
}
is called from two threads, do the threads share a single closure or each get
their own separate closure?
njs
Leopold Toetsch
> When a sub that closes over a variable
> my $closure = 0;
> sub do_something {
> return $closure++:
> }
> is called from two threads, do the threads share a single closure or
> each get their own separate closure?
AFAIK: the closure bytecode is shared, the Closure PMC with the lexical
pad is distinct. But that all isn't implemented yet.
> njs
leo
Nigel Sandever
>Nigel Sandever <nigels...@btconnect.com> wrote:
>
>> When a sub that closes over a variable
>
>> my $closure = 0;
>> sub do_something {
>> return $closure++:
>> }
>
>> is called from two threads, do the threads share a single closure or
>> each get their own separate closure?
>
>AFAIK: the closure bytecode is shared,
Great.
>the Closure PMC with the lexical
>pad is distinct.
I think that makes perfect sense. No implicit sharing.
>But that all isn't implemented yet.
>
Understood. I am being premature in thinking about this.
But this is where I come unstuck. What would this mean/do when called from 2
threads?
my $closure :shared = 0;
sub do_something {
return $closure++:
}
or this:
our $closure :shared = 0;
sub do_something {
return $closure++:
}
I struck me a while back that there is a contradiction in idea of a shared,
'my' variable.
I want to say lexical, but a var declared with 'our' is in some sense lexical.
Where I am going is that "shared" implies global. Access can be constrained by
requiring a lexical declaration using 'our', but 'my' variables should not be
able to be marked 'shared'.
One nice thing that falls out of that, is that no 'my' vars would ever be
shared, which means they never require semaphore checks. That would mean that a
non threaded app running on a multi-threaded build of Parrot, need never incur a
penalty of semaphore checks if it always use 'my'. *I think*?
In effect, all vars declared 'our' would be implicitly shared, (and would
require semaphoring), removing the need for a 'shared' attribute.
In P5, lexicals are already quicker that globals, so any additional penalty
added to globals because of multithreading will not affect any single-threaded
code that is striving for ultimate performance, because they would already be
utilising lexicals.
Equally, things like filehandles are inherently process-global in scope and
therefore sharable between threads and require semaphore checks.
I only throw this into the thought-pot because there seems to me to be a natural
symmetry between the concept of 'global' and the concept of 'shared'.
I won't argue the case for this, but I thought that if I mention it, it might
also make some sense to others when the time comes for this stuff to be designed
and implemented.
>> njs
>
>leo
>
njs
>
Martin D Kealey
> I struck me a while back that there is a contradiction in idea of a shared,
> 'my' variable.
>
> I want to say lexical, but a var declared with 'our' is in some sense lexical.
Shared-between-threads and shared-between-scopes are orthogonal properties;
using "our" or "my" controls access by lexical scope; something else is
needed to control access by thread, and ":shared" is as good as anything.
The only exception to this orthogonality is that anything within a closure
is not shared between threads -- but of course, that is only sensible
because it is not even shared between multiple closures *within* a thread.
-Martin