Threading, mutexes, tokens...

[Ivan Voras]

Joerg Sonnenberger wrote:
On Thu, Feb 03, 2005 at 12:37:24PM +0100, Ivan Voras wrote:

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.
I think I get it. For example: thread A locks a mutex, then does 
something and calls a function/subsystem that also wants to lock the 
same mutex - in that case thread A needs to know that the subsystem 
needs the mutex and release it before calling it?

Doesn't that create a short period of time (race?) when nobody holds the 
mutex and it can be snatched by another, unrelated thread or subsystem? 
(but this doesn't seem so important - the subsystem that needs the mutex 
will just wait?)

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.
I know what mutexes and blocking are, what races, deadlocks and 
livelocks are, but I still don't get how the token-principle works (how 
it does what it does :) ) Are tokens also described in Tannebaum's?