Furthermore, it’s almost a guarantee on a virtualized system that
you’ll end up some day with your virtual processor unscheduled right
in the middle of something that you thought was “very, very fast.”
- Jake Oshins
“Mark Roddy” wrote in message
news:xxxxx@ntdev…
On an MP system there simply is no guarantee of that “very, very fast”
quality. The spinlock busy wait can be deferred indefinately by
interrupts, unless of course the spinlock busy wait is executed at a
high enough interrupt level to prevent such indeterminacy.
On Dec 28, 2007 10:40 AM, Alberto Moreira wrote:
Preemption here is hardware. An interrupt happens, generates the
equivalent
of a forced call to an isr. The isr gets control, does whatever it
needs to
do very, very fast, and irets back to the caller, who keeps on
spinning. And
the whole point of spinning is exactly that you know that you need to
hog
the processor on that spinning loop, because it isn’t safe to proceed
otherwise.
And if you use the opportunity to wrestle processor control away from
the
spin loop, you’re engaging in dangerous behavior that can easily lead
into a
deadlock or livelock. That’s when that “contract” thing becomes
necessary,
and all hell breaks loose because people want to embellish a barebones
construct into something it was never meant to be.
The way I see it, and I may be wrong, even when a spinlock loop can be
preempted by the hardware, it should not be interfered with by the OS.
Spinlocks should be subarchitectural to the OS: the lowest peel of the
onion!
Alberto.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Thursday, December 27, 2007 6:27 PM
Subject: Re: [ntdev] Are callbacks guaranteed to run consecutively?
> 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 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 < xxxxx@ieee.org>
>> 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
>
>
>
> —
> 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
–
Mark Roddy