Preemption is allowed, but not suspension
What really is the motive for coming up with such a synch* primitive? Why
not mutex? Why not event? Why not semaphore with count == 1 ?
The motive is not to trap the HW in an useless state. If preemption is not
allowed, how would the system maintain other higher priority problem(s) and
tasks ( clocks, instruction OP code problems, and other stuff ).
The context switching is one of the culprit ( heavy over head ) of those
suspendable synch primitive. A suspendable synch primitive is one where the
acquiring thread could be suspended, and rescheduled, and again suspended
…
It is definitely this suspension, that motivated spinlock. Now if they are
also not preemptible then there is a real problem though.
It is altogether a different story, if someone tries to optimize the bus
traffic by not polling the flag/lock too often, but that is still spinning
and not suspending or going to wait state where scheduler/dispatcher -
intervention is needed to bring the said thread into execution.
-pro
On Dec 27, 2007 2:26 PM, Alberto Moreira wrote:
> A spinlock is supposed to stall a processor. It’s a strong tool to be
> used as an arbiter of last resort. It works like this:
>
> top: atomic_test_and_set location,true
> jump_if_old_value_is_true top
>
> Or, in C-like prose,
>
> do
> {
> old_value = atomic_test_and_set (flag,true);
> }
> while (old_value);
>
> To clear a spinlock is even simpler:
>
> flag = false;
>
> There’s no yielding of any sort here. Spinlocks don’t block, don’t yield,
> and they’re also not aware of processes, threads, or whatever. It may be the
> case that an interrupt causes a context switch, but once control comes back,
> the loop carries on. And I’m definitely not sold on the wisdom of allowing
> certain kinds of interrupts and locks to be preempted.
>
> You can dress up a spinlock with all sorts of extra baggage, but the more
> you add, the less it looks like a spinlock!
>
>
> Alberto.
>
>
>
>
> ----- Original Message -----
>
> From: Mark Roddy
> To: Windows System Software Devs Interest List
> Sent: Wednesday, December 26, 2007 10:57 AM
> Subject: Re: [ntdev] Are callbacks guaranteed to run consecutively?
>
>
>
> On Dec 26, 2007 9:22 AM, Alberto Moreira wrote:
>
> > I’m sorry, people, I’m going to put on my computer science hat now and
> > say that whatever this is, it ain’t a spinlock. The whole point of a
> > spinlock is to spin without yielding execution!
> >
>
> At least provide an accurate definition. " The whole point of a spinlock
> is to spin without yielding execution! " No that isn’t the whole point.
> That is a distinct feature. And everything we have discussed here, with the
> exception of the AIX style ‘spin a while, then sleep’ implementation,
> doesn’t ‘yield execution’. What we have discussed is that on NT, and most
> other modern multiprocessor general purpose operating systems, spinlocks are
> interruptible. The currently executing thread does not yield execution, it
> is interrupted, runs some isr, and then returns to spinning.
> Implementations of spinlocks could block all interrupts and never allow the
> processor to do anything other than busy wait for the lock. Such
> implementations are generally considered deficient as they block management
> of timers and TLBs and other critical global OS resources while not
> providing any added benefit. You are of course free to implement this sort
> of deficient simplistic private spinlock, but I would suggest not deploying
> this spinlock of yours on general purpose multiprocessor systems.
>
>
>
> >
> >
> >
> > –
> > Mark Roddy
> >
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>