in reply to Re^3: A faster?, safer, user transparent, shared variable "locking" mechanism.
in thread A faster?, safer, user transparent, shared variable "locking" mechanism.

Sometimes the scope of the CS is too big.

$shared .= <PIPE>;
would need to be written as
my $local = <PIPE>; $shared .= $local;

It should be written that way, even with explicit locking. Else, you are blocking access to $shared for much longer than necessary.

my $local = <PIPE>; { lock( $shared ); $shared = $local; }

Is far better than

{ lock( $shared ); my $local = <PIPE>; $shared = $local; }

That's a 'threading best practices' optimisation.

Sometimes the scope is too small.
# XXX. The key and value are related. my $string = $shared_key . ' => ' . $shared_value;

won't work without explicit locking.

Actually, I think it would.

C:\test>perl -MO=Terse my $string = $shared_key . ' => ' . $shared_value; ^Z LISTOP (0x191d964) leave [1] OP (0x191d948) enter COP (0x191d988) nextstate ## exception handler installed here! BINOP (0x191d9c4) sassign ## exception handler entered here and the entire subtree retried < +<<------+ ## critical section entered here (on second attempt) + | BINOP (0x191d9e8) concat [5] + | BINOP (0x191da4c) concat [3] + | UNOP (0x191da90) null [15] + | PADOP (0x191dab0) gvsv GV (0x182435c) *shared_key + | ## Exception triggered here by the access to share +d data.-+ SVOP (0x191da70) const [6] PV (0x1824374) " => " UNOP (0x191da0c) null [15] PADOP (0x191da2c) gvsv GV (0x18243b0) *shared_value OP (0x191dad0) padsv [1] ## critical section exited here. - syntax OK
Consider the following:

Each of the following lines would be self contained branches of the opcode tree.

Maybe that's just a poor example of what you are getting at.

I think the point you are trying to make is better illustrated by

{ lock( $shared ) $local = $shared; $shared = somefunction( $local ); }

Without the lock(), by the time $shared is assigned to, its value may have changed. This is true. So don't do that. Do

$shared = somefunction( $shared );

gives

C:\test>perl -MO=Terse sub somefunction{ $_[0] + 1 } $shared = somefunction( $shared ); ^Z LISTOP (0x191d7e0) leave [1] OP (0x191d7c4) enter COP (0x191d804) nextstate ## install exception handler here BINOP (0x191d840) sassign ## Exception handler catches here <<<<---------------------------^ ## Critical section entered here at second attempt UNOP (0x191d864) entersub [4] UNOP (0x191d8a0) null [141] OP (0x191d884) pushmark UNOP (0x191d8c4) null [15] PADOP (0x191d8e4) gvsv GV (0x22507c) *shared ## Exception raised here-------------------------- +-^ UNOP (0x191d904) null [17] PADOP (0x191d924) gv GV (0x225088) *somefunction UNOP (0x191d944) null [15] PADOP (0x191d964) gvsv GV (0x22507c) *shared ## ExitCriticalSection here. - syntax OK

But, there's the rub. somefunction() may legitimately take a long time, and the requirements may legitimately state that $shared cannot be accesses by other threads until it returns. And spending more than a few milliseconds in a critical section is absolutely bad.

It easy to see how to use declarative tagging of shared variables to caused multiple CSs to be used, thereby avoiding the "all access to all shared data is serialised" problem. But still, the problem of limiting the time spent within any given CS remains.

Various possibilities come to mind, for switching the CS for a semaphore transparently when certain opcodes, like entersub, are encountered within a critical section, but suddenly the simplicity of the mechanism goes away.

Oh well. Just a random thought.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.