re: serializing token

[joe pistritto <joepistritto@xxxxxxxxx>]

--- Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
wrote:
>     In fact, the fact that tokens do not deadlock
> coupled with the fact
>     that there is no expectation of atomicy for
> earlier acquired tokens
>     when later operations block leads to a great
> deal of code simplification.
>     If you look at FreeBSD-5, you will notice that
> FreeBSD-5 passes held
>     mutexes down the subroutine stack quite often,
> in order to allow some
>     very deep procedural level to temporarily
> release a mutex in order to
>     switch or block or deal with a deadlock.  There
> is a great deal of 
>     code pollution in FreeBSD-5 because of this
> (where some procedures
>     must be given knowledge of the mutexes held by
> other unrelated procedures
>     in order to function properly).
> 
>     You don't have any of that mess with the token
> abstration but there is a
>     cost and that cost is that you lose atomicy
> across blocking ops.

Matt, is it also correct to say that one also must be
very cognizant of functions that can block? Not that
this isn't a problem with mutexes either, but it is
important to know if any functions you call can block
so that you can recheck things after calling such
functions.

>     The one exception to this rule occurs in how
> DragonFly handles interrupt
>     preemption.  Since interrupts are in fact their
> own threads interrupt
>     preemption in fact switches to the interrupt
> thread, then switches back
>     to the original thread.  However, in the
> preemption case the tokens held
>     by the original thread are left acquired and if
> the interrupt thread 
>     blocks for any reason the system switches back
> to the original thread,
>     leaving the token abstraction intact from the
> point of view of the
>     original thread regardless of how many interrupt
> preemptions might occur.

I didn't quite get this. Let's say a thread A is
holding token T, protecting list L. A is then
preempted by an interrupt and the interrupt thread
also tries to acquire token T. Are you saying that
interrupt thread will block when it tries to acquire T
(because A still owns the token even though thread A
belongs to the same LWKT scheduler/CPU as the
interrupt thread)? If this isn't correct, then how do
you guarantee that L is safe in A?

Thanks so much for your answers!

-J



	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash