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

• Sometimes the scope of the CS is too big.

  $shared .= <PIPE>;
  [download]

  would need to be written as

  my $local = <PIPE>;
  $shared .= $local;
  [download]

• Sometimes the scope is too small.

  # XXX. The key and value are related.
  my $string = $shared_key . ' => ' . $shared_value;
  [download]

  won't work without explicit locking.

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:

• $shared = $shared + 1;
• $local = $shared + 1;
• my $ref = \$shared;
  $$ref = $shared + 1;

Sometimes the scope of the CS is too big.

    $shared .= <PIPE>;
[download]

would need to be written as

    my $local = <PIPE>;
    $shared .= $local;
[download]

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; }
[download]

Is far better than

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

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;
[download]

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
[download]

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 );
}
[download]

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 );
[download]

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
[download]

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.