Re: lkwt in DragonFly

[David Xu <davidxu@xxxxxxxxxxxxxx>]

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 ?

David Xu