Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report)

[Yann Guidon <whygee@f-cpu.org>]

nico wrote:
> 
> Michael Riepe a écrit :
> >
> > On Mon, Mar 18, 2002 at 03:49:07AM +0100, Christophe wrote:
> > [...]
> > > well, there is a problem with the spinlock version : what happens if a task
> > > switch occurs between the locking and the unlocking ? especially if other tasks
> > > will try to acquire the same spinlock, they all shall be blocked until the
> > > owner task may release the spinlock, which - not speaking about the invert
> > > priority problem of tasks - is in fact a real degradation. Such a thing cannot
> > > happen with CAS2 because the first to be serviced is the first to write, not
> > > the first to read - the other tasks would just need a retry - which takes
> > > basically less time to execute than waiting for owner task to unlock.
> >
> > A spinlock protected piece of code should be as short as possible, and
> > not contain blocking functions at all. Spinlocks are just a way to make a
> > sequence of simple instructions atomic -- like the update operations in
> > the stack example, or a software implementation of CAS2 (which would be
> > too heavy as a machine instruction -- remember that it has six operands).
> >
> 
> This instruction are used inside PowerPC. Maybe it's possible to "link"
> few instructions together to defined a CAS2 operation. Imagine a flag
> set, if something happen between the fetch, CAS2 are canceled. I know it
> look like CISC but here the state machine is simple : if the 3 or 4
> instructions or fetch one after an other the CAS2 op are made on the bus
> (never forget that we need this type of cycle for our internal bus), if
> something else happen it's cancelled, if the fetch begin in the "middle"
> of the 3 instructions (as after a switch) nothing happen. I thing it
> simple, no ?
> 
> nicO
> 
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> >  "All I wanna do is have a little fun before I die"
> > *************************************************************
> > To unsubscribe, send an e-mail to majordomo@seul.org with
> > unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

-- 
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/