Re: Threading, mutexes, tokens...

[Ivan Voras <ivoras@xxxxxx>]

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?