Ah, now you are speaking :-).
Yes I also agree that OS should not interfare in the sense of taking it out
of execution, put thru the grinding mills of whatever ( round robin,
priority based round robin … ) types of scheduling. But as you said the
interruptiblity should be allowed. There has to have a mechnism to let the
other high priority work to keep that processor’s sanity.
But as mark said, AIX has that yielding ( and I assume it pump the thread to
the process/thd table for it tobe scheduled later). Well it is not really a
spinlock in true spirit. And that is why I mentioned that the whole purpose
of coming up with spinlock is to reduce scheduling overhead ( as acquiring
thd finds it is wokenup and goes back to sleep, … ).
But I never said it is not “Art of computer programming”. It is very much an
art
-pro
----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Friday, December 28, 2007 7:40 AM
Subject: Re: [ntdev] Are callbacks guaranteed to run consecutively?
> 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 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