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.