Why would a programmer need to defend against this? There's no harm (except performance-wise) in Perl locking an SV internally while it's mucking with the SV's innards.

If two threads are mucking with the innards of the same SV at the same time, you have a huge problem. Locking the SV while mucking with the innards would solve that problem with no side-effects.

If you already have safeguards in place to prevent the two threads from mucking with the innards of the same SV at the same time, then this internal locking is effectively a no-op.

I guess you've never heard about deadlocks, huh? Imagine thread "Bob" has a lock on $foo and thread "Bill" has a lock on $bar. Bob wants a lock on $bar, so he sleeps waiting for the lock. Bill wants a lock on $foo, so he sleeps waiting for $bar. Neither will ever wake up because neither lock will ever become available!

Thread programming is hard and this is the reason!

-sam

I guess you've never heard about deadlocks, huh? Imagine thread "Bob" has a lock on $foo and thread "Bill" has a lock on $bar. Bob wants a lock on $bar, so he sleeps waiting for the lock. Bill wants a lock on $foo, so he sleeps waiting for $bar. Neither will ever wake up because neither lock will ever become available!

And if the golden rule of locking is followed?

If you have to acquire multiple concurrent locks(*), always acquire the locks in the same order

(*and it's actually rarely required with good algorithms).

Thread "Bill" knows he needs locks on $foo and $bar, so he requests them

lock( $foo, $bar );
## do stuff with $foo & $bar
[download]

And thread "Bob" requires locks on just $bar, so that's what he asks for

lock( $bar );
## Do stuff with $bar
[download]

The implementation of lock sorts its arguments according to some criteria, and attempts to acquire the locks in that order. The criteria doesn't matter so long as it is always the same, but address order is convenient.

Now the deadlock can never occur. The implementation of the list form of lock() is trivial.

And if locks are (can be?) applied automatically, its easy to enforce this rule.

Thread programming is hard and this is the reason!

Threading isn't (overly) hard. (When compared to other forms of parallelisation.)

Locking can catch out the unknowing, but locking applies to many more things than threading--file locking; record locking; bi-directional protocols with 2-way handshaking; and more.

In most cases, certainly at the application level, requiring multiple concurrent locks is an indication of a bad algorithm. Algorithm design is complex in any field.

In most cases of threading there is no need for multiple concurrent locks, but when there is, like many other fields of programming there are 1 or 2 simple, well known and clearly defined rules to follow. And with better infrastructural support for locking, its quite possible to have the infrastructure enforce those rules.

---

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.