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

Ah, you mean to hold the lock for all the child opcodes as well. In that case, the Anonymous Monk already answered

As you can see, the user still needs to be fully aware of the locking mechanism and must sometimes compensate for it. The only thing accomplished is the removal of the visual cues that something special is happening.

And that's assuming you can figure out where to end the critical section. Consider the following:

Replies are listed 'Best First'.
Re^4: A faster?, safer, user transparent, shared variable "locking" mechanism.
by BrowserUk (Patriarch) on Oct 26, 2006 at 22:05 UTC

    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.

    • $shared = $shared + 1;

      This is the case I addressed above.

    • $local = $shared + 1;

      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?

    • my $ref = \$shared;

      This doesn't touch the shared data at all.

    • $$ref = $shared + 1;

      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.


    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.