Re: serializing token

[Dave Leimbach <leimySPAM2k@xxxxxxx>]

Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> writes:

>     Writing code the API is fairly simple, but it does depend on what you
>     do 'inside' the area being protected by the token.  The vast majority
>     of code that uses tokens, just as with mutexes, does not do anything fancy
>     within the protected area and doesn't really have to worry about any of
>     these issues.  For the remaining code you either have to be aware of the
>     exact side effects (with mutexes), or you have to program defensively
>     if you are not sure what a lower layer will do (with tokens).
> 
>     There is also a huge class of code where no rechecking is needed.  Take
>     this for example:
> 
>     if (someglobal) {
> 	lwkt_gettoken(..)
> 	while (someglobal) {
> 	    someglobal &= ~someotherprocedurethatmightbloc();
> 	    call procedure that might block()
> 	}
> 	lwkt_reltoken(..)
>     }

Let's assume for a minute that the above code is a consumer on a work-queue
and that the "if (someglobal)" evaluates true if there is work to be done.

Would this "gettoken" "reltoken" usage be suitable to support a consumer on
a work queue?

Clearly the ability to call blocking functions while holding the lock is a 
nice feature :). 

> 
>     This code snippit above is using a token to protect a global variable.
>     It is able to optimize itself by not bothering to get the token unless
>     it thinks it has work to do, and then integrating the recheck case in
>     the while().  The token is protecting against preemptive modifications
>     to the global variable rather then protecting against changes made to
>     the global variable by the called procedures or as a side effect if 
>     either procedure blocks.
> 

What would be a change to the global variable that the token doesn't protect 
if th thread does block on one of those procedures?  

What does the scheduler do when another thread tries to get the token and
the original token holder is blocked?  I think the answer to this question
may clarify to me how this works better.



>     The really complex cases are relatively few... cases involving structural
>     pointers such as unreferenced vnode pointers, vm_page's, and so forth.
>     There are plenty of ways to protect such structures.  The vnode case is
>     probably the most complex (and it is just as complex or even more complex
>     when implemented with mutexes), most of the rest of the structures can be
>     prevented from moving around with a ref count.
> 

Is the reference count protected by tokens or mutexes? :)

> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>