lkwt in DragonFly

David Xu davidxu at viatech.com.cn
Mon Feb 9 19:36:11 PST 2004



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







More information about the Kernel mailing list