I *think* that it is safe to say that the locked attribute is a pthreads throwover that doesn't serve any purpose with ithreads.

When you spawn your threads, they each end up with their own seperate copies of your sub f(), along with (almost) everything else in the interpreter.

P:\test>perl -Mthreads -l
$|=1;
sub f{ print $_[0]; sleep 5; print $_[0]; }
threads->create( \&f, \&f ) for 1..2;
$_->join for threads->list;
print 'done';
^Z
CODE(0x1bf9b7c)
CODE(0x1c23c24)
CODE(0x1bf9b7c)
CODE(0x1c23c24)
done
[download]

As you can see, the purpose of :locked subroutine attribute is completely negated by the design of ithreads.

The problem is that whilst it is possible at the system (C/OS) level to share code between threads and have seperate copies of data (ie. reentrent code), at the perl interpreter level, it is not. Perl (byte)"code" is simply another form of data at the system level, and is not reentrant. Hence, the ithreads design works around this by creating copies of the entire (system level) data segments which in perl terms means that all user-level code is also replicated. It's an unfortunate fact of life that perl long history means that adapting the current sources to allow true threading at the perl level is not viable, even on platforms that support threading natively. Re-writing the compiler and interpreter to segregate the perl code from the perl data such that perl code would become reentrant would be a nightmare to undertake.

I think this may be one of the motivations behind Ponie, though that's a guess as I've yet to see it stated, and if it is, it is only one of many,