in reply to (ithreads) :locked subs

Not exactly. attributes says:
locked

Setting this attribute is only meaningful when the subroutine or method is to be called by multiple threads. When set on a method subroutine (i.e., one marked with the method attribute below), Perl ensures that any invocation of it implicitly locks its first argument before execution. When set on a non-method subroutine, Perl ensures that a lock is taken on the subroutine itself before execution. The semantics of the lock are exactly those of one explicitly taken with the lock operator immediately after the subroutine is entered.

And that's basically what happens (i think you misunderstand what locking does). 
#!/usr/bin/perl -w -l --  
@ARGV = qw[ foo bar baz ];
use threads;
$|=1;
sub f :locked {
    my $tid = threads->self()->tid();
    print "A}$tid}$_[0]";
    select undef, undef, undef, rand(2);
    print "B}$tid}$_[0]";
}
threads->create(\&f, $_) for @ARGV;
$_->join() for threads->list() 
__END__

A}1}foo
A}2}bar
A}3}baz
B}3}baz
B}2}bar
B}1}foo


#!/usr/bin/perl -w -l --  
@ARGV = qw[ foo bar baz ];
use threads;
$|=1;
sub f :locked {
    my $tid = threads->self()->tid();
    print "A}$tid}$_[0]";
    select undef, undef, undef, rand(2);
    print "B}$tid}$_[0]";
}
threads->create(\&f, $_) for @ARGV;
$_->join() for threads->list() 
__END__

A}1}foo
A}2}bar
A}3}baz
B}1}foo
B}2}bar
B}3}baz

[download]

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
** The third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: (ithreads) :locked subs
by Anonymous Monk on Sep 24, 2003 at 07:13 UTC
    Hmm...in your example there's no evidence that a lock is "taken on the subroutine itself" -- it's clear that threads 1, 2, and 3 are executing f() concurrently, which is contrary to the purpose of :locking a subroutine.

    Let me rephrase -- I expected :locked subs to function like the docs indicate that the (not available under 5.8) manual lock()ing of a CODEREF (that is, lock(\&f)) used to function. That is, that invocations of ":locked" or ":locked :method" subs would be synchronized and thus serialized, rather like sync'd methods in Java.

    By way of illustration, this is the moral equivalent of what I expected :locked to do:

    #! /usr/bin/perl
use threads;
use threads::shared;
$|=1;
{
my $l : shared;  # private lexical
sub f() {
  lock($l);      # any f() in any thread is "locked"
  my $tid = threads->tid();
  print "A}$tid}$_[0]\n";
  select undef, undef, undef, rand(2);
  print "B}$tid}$_[0]\n";
}
} # -- end scope for $l

threads->create(\&f, $_) for (qw|foo bar baz|);
$_->join() for threads->list();
__END__

    [download]

    Run it and you'll see that the threads are locking each other out. A useful device to prevent shared state corruption, very much like Java's "synchronized" keyword.

    I'm having a hard time reading attributes.pm any other way.

[reply]
[d/l]
      *foreheadslap* I see what you're saying, but I fear the docs are misleading then(or its a bug). It's not like you can lock(@_) and expect it to work sensibly (whatever that means). BrowserUks got a better beat on it.

      MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
      I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
      ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]

In Section Seekers of Perl Wisdom