Is there a kernel function that yeilds the remainder of the current thread timeslice? Oh, and not dependent on the current IRQL being PASSIVE_LEVEL. (assuming we’re on multiprocessor system)
My guess would be KeDelayExecutionThread(KernelMode,TRUE,1) but that is only
in PASSIVE_LEVEL. At higher IRQL levels there is no thread switching.
wrote in message news:xxxxx@ntdev…
>
> Is there a kernel function that yeilds the remainder of the current thread
timeslice? Oh, and not dependent on the current IRQL being PASSIVE_LEVEL.
(assuming we’re on multiprocessor system)
>
>
>
You’re saying that at DISPATCH_LEVEL all the processors on the machine would halt all threads that are running at or below DISPATCH_LEVEL? In that case the spinlocks that get aquired at DISPATCH_LEVEL, would be burning lots of CPU ticks if they don’t yeild timeslice if they can’t do the aquisition?
Any thoughts?
-----Original Message-----
From: Doug [mailto:xxxxx@hotmail.com]
Sent: Tuesday, January 28, 2003 4:22 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Releasing Timeslice
My guess would be KeDelayExecutionThread(KernelMode,TRUE,1) but that is only
in PASSIVE_LEVEL. At higher IRQL levels there is no thread switching.
wrote in message news:xxxxx@ntdev…
>
> Is there a kernel function that yeilds the remainder of the current thread
timeslice? Oh, and not dependent on the current IRQL being PASSIVE_LEVEL.
(assuming we’re on multiprocessor system)
>
>
>
—
You are currently subscribed to ntdev as: xxxxx@krollontrack.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
when any processor in the system is raised to DISPATCH_LEVEL or above no
thread scheduling occurs on that processor until the one in control
lowers back down below DISPATCH_LEVEL. Higher priority interrupts can
occur, but quantum end won’t happen.
Spinlocks do indeed spin waiting for the lock to become available. This
is implied in the name (SPINlock).
-p
-----Original Message-----
From: xxxxx@KrollOntrack.com [mailto:xxxxx@KrollOntrack.com]
Sent: Tuesday, January 28, 2003 3:58 PM
To: NT Developers Interest List
You’re saying that at DISPATCH_LEVEL all the processors on the machine
would halt all threads that are running at or below DISPATCH_LEVEL? In
that case the spinlocks that get aquired at DISPATCH_LEVEL, would be
burning lots of CPU ticks if they don’t yeild timeslice if they can’t do
the aquisition?
Any thoughts?
-----Original Message-----
From: Doug [mailto:xxxxx@hotmail.com]
Sent: Tuesday, January 28, 2003 4:22 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Releasing Timeslice
My guess would be KeDelayExecutionThread(KernelMode,TRUE,1) but that is
only in PASSIVE_LEVEL. At higher IRQL levels there is no thread
switching.
wrote in message news:xxxxx@ntdev…
>
> Is there a kernel function that yeilds the remainder of the current
> thread
timeslice? Oh, and not dependent on the current IRQL being
PASSIVE_LEVEL.
(assuming we’re on multiprocessor system)
>
>
>
—
You are currently subscribed to ntdev as: xxxxx@krollontrack.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
As said by another person, DISPATCH_LEVEL stops thread switching for that
processor. Other processors can be doing other things. Spinlocks burn lots
of CPU so you should only hold them a very short time. While they are held,
no thread switching goes on, but higher level IRQLs can come in (which is
why you have regular spinlocks and InterruptSpinLocks).
wrote in message news:xxxxx@ntdev…
>
>
> You’re saying that at DISPATCH_LEVEL all the processors on the machine
would halt all threads that are running at or below DISPATCH_LEVEL? In that
case the spinlocks that get aquired at DISPATCH_LEVEL, would be burning lots
of CPU ticks if they don’t yeild timeslice if they can’t do the aquisition?
>
> Any thoughts?
KeDelayExecutionThread with zero timeout. Can be used on <
DISPATCH_LEVEL.
There is no notion of “timeslice” on >= DISPATCH_LEVEL.
Max
----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Wednesday, January 29, 2003 12:42 AM
Subject: [ntdev] Releasing Timeslice
> Is there a kernel function that yeilds the remainder of the current
thread timeslice? Oh, and not dependent on the current IRQL being
PASSIVE_LEVEL. (assuming we’re on multiprocessor system)
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
No, IRQL is a per-CPU notion, so, one CPU being on DISPATCH_LEVEL will
not alter the scheduling state of the other CPUs.
DISPATCH_LEVEL means - postponing all thread switches till the IRQL
will be lowered - by draining the DPC queue or by releasing a spinlock
usually.
Max
----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Wednesday, January 29, 2003 2:57 AM
Subject: [ntdev] Re: Releasing Timeslice
>
> You’re saying that at DISPATCH_LEVEL all the processors on the
machine would halt all threads that are running at or below
DISPATCH_LEVEL? In that case the spinlocks that get aquired at
DISPATCH_LEVEL, would be burning lots of CPU ticks if they don’t yeild
timeslice if they can’t do the aquisition?
>
> Any thoughts?
>
>
>
> -----Original Message-----
> From: Doug [mailto:xxxxx@hotmail.com]
> Sent: Tuesday, January 28, 2003 4:22 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Releasing Timeslice
>
>
> My guess would be KeDelayExecutionThread(KernelMode,TRUE,1) but that
is only
> in PASSIVE_LEVEL. At higher IRQL levels there is no thread
switching.
>
> wrote in message news:xxxxx@ntdev…
> >
> > Is there a kernel function that yeilds the remainder of the
current thread
> timeslice? Oh, and not dependent on the current IRQL being
PASSIVE_LEVEL.
> (assuming we’re on multiprocessor system)
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
xxxxx@krollontrack.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>