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
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 topOr, 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