Diff for /site/data/goals/Attic/threads.cgi between versions 1.5 and 1.6

version 1.5, 2004/02/15 20:04:05 version 1.6, 2004/02/22 15:34:35
Line 101  synchronization interface operates in a Line 101  synchronization interface operates in a
 back functions tend to work just like the callback functions used in the  back functions tend to work just like the callback functions used in the
 IPI messaging subsystem.  IPI messaging subsystem.
 <P>  <P>
<CENTER>Token Passing Primitives Not Mutexes</CENTER><CENTER>Serializing Tokens</CENTER>
 
 <P>  <P>
The LWKT model implements a token passing primitive rather then a mutexA serializing token may be held by any number of threads simultaneously.
primitive.  Tokens are owned by cpus rather then by threads, and a changeA thread holding a token is guaranteed that no other thread also
of ownership is protected by a critical section (another cpu has to IPI messageholding that same token will be running at the same time.
you to pull your token away from you).  A token can be made to act almost like<P>
a mutex by releasing it to NOCPU, but generally speaking a token is eitherA thread may hold any number of serializing tokens.
passively released (left owned by the current cpu), or actively handed off to<P>
another cpu.  The release mechanism used depends on the circumstances.  AA thread may hold serializing tokens through a thread yield or blocking
token that is ping-ponging (typical in a pipe) is best served by an activecondition, but must understand that another thread holding those tokens
hand off, for example.  The primary advantage of the token over the mutexmay be allowed to run while the first thread is not running (blocked or
is that it costs almost nothing to acquire a token that your cpu already owns,yielded away).
and costs even *LESS* to release a token because you effectively do not actually<P>
have to release it.  The biggest disadvantage is that acquiring a token ownedThere are theoretically no unresolvable deadlock situations that can
by another CPU requires a synchronous IPI message.  This disadvantage canarise with the serializing token mechanism.  However, the initial
be partially compensated for by having the release go to NOCPU (then the tokenimplementation can potentially get into livelock issues with multiply
may be acquired through a locked cmpxchgl in IA32-land), but it is ourheld tokens.
belief that most token operations can be optimal enough such that the cost<P>
of the occassional IPI will be on average less then the cost of a mutex.Serializing tokens may also be used to protect threads from preempting
The token code really is a lot less complex then the mutex code.  We don'tinterrupts that attempt to obtain the same token.  This is a slightly
have to worry about deadlocks, we don't have to release tokens when we block,different effect from the Big Giant Lock (also known as the MP lock),
there are a whole lot of special cases that simply do not exist when usingwhich does not interlock against interrupts on the same cpu.
a token model.<P>
 Holding a serializing token does <B>not</B> prevent preemptive interrupts
 from occuring, though it might cause some of those interrupts to 
 block-reschedule.
 

Removed from v.1.5  
changed lines
  Added in v.1.6