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.

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

Yes, yes, yes, but you don't have that option if the language does locking automatically for you - and you may not be aware that it's actually locking, do you?

For the first post in this thread, I got the impression that you want Perl to automatically lock a variable whenever its being changed. Now, you can't simultaneously take this out of the hands of the programmer, and make her responsible for the order in which locking occurs.