Re: why spinlock raises IRQL to DISPATCH

I think saying the scheduler runs at DISPATCH_LEVEL will lead to many
problems for people to understand it correctly. It runs when the IRQL is
going to drop below DISPATCH_LEVEL. If you say that the scheduler runs at
DISPATCH_LEVEL you can be lead to believe that multiple threads can run at
DISPATCH_LEVEL on the same CPU.

I have always wondered if a CPU is running a thread at DISPATCH_LEVEL and a
hardware interrupt occurs, how does the hardware/OS decide to use that CPU
or another that might be running at passive. If the other CPU was running
at DIRQL, will that thread that was preempted be switched to the first CPU
that drops below DIRQL? Keeping the stacks straight might be a problem in
doing that. I guess you could have a CPU that is running at passive while
another is running at DIRQL and keeping a DISPATCH_LEVEL from running.

"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:%234VWgvhWFHA.2684@xxxxxxxxxxxxxxxxxxxxxxx
> Maybe need to add ( for full clearance ) that the thread scheduler run at
> DISPATCH_LEVEL , so that's the way of disable sheduling
> Arkady
> "Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message
> news:6z0ie.17732$sV7.4879@xxxxxxxxxxx
>
>> Because a spinlock has other threads spin on the lock. If you do not
>> disable scheduling you can create a situation where most of your systems
>> CPU time is spent spinning on locks, and where a low priority thread has
>> acquired the lock then is starved by spinning to the point that it taks a
>> long time to release it.
>>
>> Spin locks are spupposed to be low overhead locks for short periods of
>> use. Note: on a uniprocessor implementation the lock is never set, the
>> implementation is just raise to dispatch to disable scheduling.
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>> "Bajamani" <bajamani@xxxxxxxxxxx> wrote in message
>> news:1116246989.835297.82030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>> Why does spinlock implementation raise the irql to dispatch level? just
>>> acquiring the lock at passive level should prevent other threads from
>>> accessing the same lock.
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: why spinlock raises IRQL to DISPATCH
    ... I think saying the scheduler runs at DISPATCH_LEVEL will lead to many ... DISPATCH_LEVEL on the same CPU. ... on a uniprocessor implementation the lock is never set, ... implementation is just raise to dispatch to disable scheduling. ...
    (microsoft.public.development.device.drivers)
  • Re: [rfc] [patch] mm: Slab - Eliminate lock_cpu_hotplug from slab
    ... cpu won't disappear from the bitmask. ... err = -EBUSY; ... is it not possible to take the per scheduler subsystem lock at DOWN_PREPARE ...
    (Linux-Kernel)
  • 2.6.19-rc2 cpu hotplug lockdep warning: possible circular locking dependency
    ... Note that this is plain 2.6.19-rc2 (_without_ the slab cpu ... which lock already depends on the new lock. ... Using ACPI for SMP configuration information ... # ACPI Support ...
    (Linux-Kernel)
  • One minute delay when booting 2.6.24.1
    ... Switched to high resolution mode on CPU 1 ... io scheduler anticipatory registered ... # Infrared-port device drivers ...
    (Linux-Kernel)
  • [RFC][PATCH] O(1) Entitlement Based Scheduler
    ... This patch is a modification of the Oscheduler that introduces ... _entitlement_ to CPU resources that is determined by the number of _shares_ ... This patch provides both soft and hard CPU usage rate caps per ... one getting the most can be given a better priority, ...
    (Linux-Kernel)