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.