serializing token
Matthew Dillon
dillon at apollo.backplane.com
Sat Apr 24 22:40:08 PDT 2004
:> Now a stupid question, I've been following the descriptions of what a
:> serializing token is, and if I'm understanding, a serializing token
:> while you are holding it, guarantees that you are the only one running
:
:add: who wants/has the token
:
:> on a given cpu until you block or release the token. Is it as simple as
:> that ?
:>
:> Andrew.
:>
Multiple threads can be holding the same token, but only one of those
threads will be running at any given moment (hence the token serializes
the threads).
e.g.
thread1()
{
get token
a
b
c
block
d
e
f
rel token
}
thread2()
{
get token
a
b
c
block
d
e
f
rel token
}
Only one of these thread will get the token initially. Lets say thread1
gets the token. When thread1 blocks, thread2 will be able to get the
token and thread1 will not be resumed until thread2 blocks or releases
the token. thread2 now blocks, and thread1 is resumed. Thread2 will
not run again until thread1 blocks or releases the token.
thread1 thread2
get token get token
a [block]
b
c
block -> [get token returns]
a
b
c
[thread1 resumes] <- [block]
d
e
f
rel token -> [thread2 resumes]
d
e
f
rel token
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>
More information about the Kernel
mailing list