DragonFly kernel List (threaded) for 2004-02
Re: lkwt in DragonFly
Matthew Dillon wrote:
My new token idea takes the original per-cpu idea and abstracts it
into a serialization model. We could, in fact, even support 'reader'
and 'writer' refs to tokens in order to allow multiple readers to
hold the same token at the same time. The key difference between
the new token idea and, say, a standard lock, is that the token is
only in effect while the thread that acquired it is running. When
the thread blocks or switches away the tokens that thread has acquired
can be borrowed by other threads (on the same or on other cpus) and
must be returned before the original thread can resume.
So, unlike mutexes or locks, a token only guarentees run-time
serialization. A token also has no deadlock issues and no lock
ordering issues at all. Like mutexes, code that uses tokens must
be aware of potential blocking conditions (because atomicy is lost
across a blocking operation), but unlike mutexes the code that
uses tokens does not have to release the tokens across the blocking
operation. I believe this to be a VERY IMPORTANT feature of the
new token design because it means we can (A) hold multiple tokens
across a blocking situation, (B) higher level procedures do not need
to pass token references to lower level procedures that 'might block',
they need only be aware that the lower level procedure might block,
and (C) the new token abstraction leaves open the possibility of
major implementation optimizations because it devolves nearly into
a NOP on UP systems. e.g. we can support per-cpu 'caching' of the
token after it has been released, allowing us to avoid locked bus
cycles as well as memory barriers in the cache case.
One thing I am not clear is that obtaining a token owned by another
CPU is a blocking operation or not ? if CPU A owning a token T1 wants
to obtain a token T2 which is being owned by CPU B, and CPU B wants to
obtain token T1, isn't it a dead lock or not ?