develooper Front page | perl.perl6.language.flow | Postings from August 2000

Re: RFC 178 (v1) Lightweight Threads

Thread Next
From:
Steven W McDougall
Date:
August 31, 2000 18:49
Subject:
Re: RFC 178 (v1) Lightweight Threads
Message ID:
200009010146.VAA22979@world.std.com
> Steven W McDougall wrote:
> > > The more interesting case is this:
> > >
> > >     #!/my/path/to/perl
> > >     sub foo_generator { my $a = shift; sub { print $a++ } }
> > >     my $foo = foo_generator(1);
> > >     $foo->();
> > >     Thread->new($foo);
> > 
> > > Is $a shared between threads or not?
> > 
> > $a is shared between threads.
> > The anonymous subroutine is a closure.
> > Closures work across threads.
> 
> That's a possibility, but it has severe implementation problems --
> all closures must be treated as having shared variables. That makes
> closures really expensive. The use of "our" vs. "my" for mutex locking
> becomes (almost) useless.

How do `our' and `my' control mutex locking?


You don't need closures to share block-scoped lexicals across threads.
All you have to do is pass a reference into a threaded subroutine.

    sub foo
    {
        my $a;
	Thread->new(\&bar, \$a);
	$a++;
    }

    sub bar
    {
	my $a = shift;
	$$a++;
    }


or just declare one subroutine within the scope of another

    sub foo
    {
        my $a;
	Thread->new(\&bar);
	$a++;

	sub bar
	{
	    $$a++;
	}
    }


> If I change the above code to:
> 
>     #!/my/path/to/perl
>     sub foo_generator { our $a = shift; sub { print $a++ } }
>                         ###
>     my $foo = foo_generator(1);
>     $foo->();
>     Thread->new($foo);
> 
> then I'd expect $a to be shared. I'm not so sure otherwise -- the
> performance cost might be too big.

In this example, does `our' have the Perl 5.6.0 semantics, or some new
semantics that controls whether variables are shared between threads?


- SWM



Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About