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