15/04/2005 10:35:56, Leopold Toetsch <[EMAIL PROTECTED]> wrote:

>Nigel Sandever <[EMAIL PROTECTED]> 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

>



Reply via email to