Re: Threading, mutexes, tokens...
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?
討論串 (同標題文章)
完整討論串 (本文為第 3 之 4 篇)：