Re: Re: (ithreads) :locked subs

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 :)

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]