Parrot bytecode reentrancy

3 views
Skip to first unread message

Nigel Sandever

unread,
Mar 31, 2005, 5:57:22 PM3/31/05
to perl6-i...@perl.org
Is Parrot bytecode reentrant?

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

unread,
Mar 31, 2005, 9:17:39 PM3/31/05
to Nigel Sandever, perl6-i...@perl.org
At 05:57 PM 3/31/2005, Nigel Sandever wrote:
>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

unread,
Apr 14, 2005, 8:33:05 PM4/14/05
to perl6-i...@perl.org
On Thu, 31 Mar 2005 21:17:39 -0500, mrjol...@mindspring.com (MrJoltCola)
wrote:
Thanks. Another question arises.

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

unread,
Apr 15, 2005, 5:35:56 AM4/15/05
to Nigel Sandever, perl6-i...@perl.org
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, the Closure PMC with the lexical
pad is distinct. But that all isn't implemented yet.

> njs

leo

Nigel Sandever

unread,
Apr 15, 2005, 11:18:27 AM4/15/05
to Nigel Sandever, l...@toetsch.at, perl6-i...@perl.org
15/04/2005 10:35:56, Leopold Toetsch <l...@toetsch.at> wrote:

>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

unread,
Apr 17, 2005, 7:01:54 PM4/17/05
to perl6-i...@perl.org
On Fri, 15 Apr 2005, Nigel Sandever wrote:
> 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


Reply all
Reply to author
Forward
0 new messages