Re: (ithreads) :locked subs

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,

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.

Comment on Re: (ithreads) :locked subs Download Code

Replies are listed 'Best First'.
Re: Re: (ithreads) :locked subs by Anonymous Monk on Sep 24, 2003 at 07:38 UTC
It has been written: `As you can see, the purpose of :locked subroutine attribute is compl +etely negated by the design of ithreads.` [download] Well, the purpose (as I understand it) is still valid, I'd say. You certainly want to be able to lock() manipulations of `:shared` (or shared()) variables. If this simply isn't possible in 5.8, well, bummer. Indeed, `threads::shared` lock()s are BLOCK-based. Very convenient to name those blocks (as subs/methods), and synchronize their execution, automagically. (Hmm -- maybe time to get an account, if just for this thread, er, ithreads :)	[reply] [d/l]
Re: Re: Re: (ithreads) :locked subs by BrowserUk (Patriarch) on Sep 24, 2003 at 08:45 UTC
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! Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller If I understand your problem, I can solve it! Of course, the same can be said for you.	[reply] [d/l] [select]