DragonFly kernel List (threaded) for 2004-04
Re: serializing token
joe pistritto <joepistritto@xxxxxxxxx> writes:
> --- Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
> > 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
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
> > 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.
> Thanks so much for your answers!
> Do you Yahoo!?
> Yahoo! Photos: High-quality 4x6 digital prints for 25¢