Re: serializing token

[Dave Leimbach <leimySPAM2k@xxxxxxx>]

joe pistritto <joepistritto@xxxxxxxxx> writes:

> --- 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.

Is it true that functions that can block can cause 
a release of a token?  Is that actually a "must
cause the release of a token"?  If so then 
being able to print out source code and highlight
critical sections seems like it might be more 
difficult for the new coder than say a mutex based
locking system.

> 
> >     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?
> 

If the interrupt can get the token then it's even harder
to draw a critical section in code where data is 
consistent.  Also shouldn't some interrupts be treated with
a higher priority than others?

How can I write code with this API and know without a doubt
that my data is how I left it.

Dave


> 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