Threading, mutexes, tokens...

[Joerg Sonnenberger]

On Thu, Feb 03, 2005 at 12:37:24PM +0100, Ivan Voras wrote:
> I see this is fairly different (trivially simple?) than situations 
> reffered to in various posts explaining mutexes and tokens - 
> specifically, I don't "see" the need for "With a hard mutex model you 
> have to pass your mutex down into other subsystems that you call so they 
> can release it before they potentially block, or you have to temporarily 
> release your mutex yourself, or a myrid of other issues" (quote from 
> Matt's recent interview). I'm not experienced enough, so could someone 
> give me a pseudocode-example of this (prefferably in a real-world case?)?

The reason why subsystems has to be aware of mutexes is the dead lock risk.
You don't want a thread holding a mutex block for an arbitrary period of
time, because all other threads needing that mutex would be blocked too.
If you now add the implications of locking necessary e.g. for memory
allocations under memory scarvation situations, you also have a very
easy way to dead lock or semi-dead lock a system.

If you want to ensure dead-lock freeness via easy to evaluate rules
[this is what WITNESS does], so end up disallowing all blocking
operations while holding a mutex.

With the tokens, you have to be aware of blocking operations too,
because they interrupt the serialisation and allow other threads
to change the protected data structures. But instead of having to
worry about releasing / reacquiring the token, you can depend on 
the system to manage it automatically. Dead locks are simply not
possible because the "blocking for lock while holding another lock"
condition doesn't exist. If you don't know what I mean, grab a copy
of Modern Operating Systems from Andre Tannebaum or a similiar book.

Joerg