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.
would need to be written as$shared .= <PIPE>;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.
This is the case I addressed above.
This is a readonly reference to the shared variable (in user land, though it may entail writes in perl land if $shared need promotion to an IV or NV).
$local takes no further part in this snippet.
I don't see how, on the basis of this snippet, this line has any affect upon the rest of them?
This doesn't touch the shared data at all.
After the dereference of $ref, this is the same as the first line.
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.
|
|---|