The function of mutexing access to shared data hasn't gone away and this function is catered for in iThreads by the use of the :shared variable attribute or threads::shared::shared() function, in conjunction with the threads::shared::lock() function.

The purpose of the :locked subroutine attribute is no longer valid, as it is impossible to share perl subroutines bewteen threads.

What my example code attempted to demonstrate is that your attempt to use the :locked attribute to prevent two threads from concurrently executing your sub f(), served no purpose as, despite surface appearance, each thread was in fact getting it's own unique copy of that sub. So even if the locked attribute semaphore code is still operational under ithreads, it would never come into effect as there will be two mutexes applied to two pieces of data (presumable the subs cv entry in the symbol table) and the two entities could never interfere with each other directly.

However, if the sub uses a shared variables (as in my $var : shared; or my $var; share( $var);), the the presence of the :locked attribute on the subroutine would not only serve no useful purpose, it might actually lull the unsuspecting into believing that they do not need to use the lock() function on the shared variables, which is inherently dangerous.

I guess that the fact that the :locked subroutined attribute doesn't raise either a syntax or unknown attribute error under iThreads should be considered a bug!