I have a scheduler thread in my NDIS IM driver. I need to have some sort of mutex like locking between threads when adding/removing from my scheduler list. Is there a safe way to lock without raising the IRQL?
Can you synchronize with purely interlocked operations? The CPU
instruction-based ones don’t touch IRQL. (The ones that take a spin
lock do, of course, although it’s done differently.)
You want to be careful importing non-NDIS functions in your driver if
you’re going to get it signed. I can’t seem to find the forbidden
imports list on a quick Google search, but it’s out there somewhere.
You should try with spin locks and profile to see if this really
matters. I bet it doesn’t. Or did you have some other reason for
wanting to stay at < DISPATCH_LEVEL?
-sd
On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
I have a scheduler thread in my NDIS IM driver. I need to have
some sort of mutex like locking between threads when adding/
removing from my scheduler list. Is there a safe way to lock
without raising the IRQL?
Questions? First check the Kernel Driver FAQ at http://
www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
My scheduler thread is started in DriverEntry using PsCreateSystemThread. What IRQL will this thread run at? My issue here is making sure I do not make any system calls at an improper IRQL so as to not cause a BSOD. Thanks…
-----Original Message-----
From: Steve Dispensa
>Sent: Jun 4, 2007 12:41 PM
>To: Windows System Software Devs Interest List
>Subject: Re: [ntdev] NDIS IM Thread Locking
>
>Can you synchronize with purely interlocked operations? The CPU
>instruction-based ones don’t touch IRQL. (The ones that take a spin
>lock do, of course, although it’s done differently.)
>
>You want to be careful importing non-NDIS functions in your driver if
>you’re going to get it signed. I can’t seem to find the forbidden
>imports list on a quick Google search, but it’s out there somewhere.
>
>You should try with spin locks and profile to see if this really
>matters. I bet it doesn’t. Or did you have some other reason for
>wanting to stay at < DISPATCH_LEVEL?
>
> -sd
>
>On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
>
>> I have a scheduler thread in my NDIS IM driver. I need to have
>> some sort of mutex like locking between threads when adding/
>> removing from my scheduler list. Is there a safe way to lock
>> without raising the IRQL?
>>
>> —
>> Questions? First check the Kernel Driver FAQ at http://
>> www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
You might want to be careful about what DDI’s you’re calling; many of
them can make your driver un-signable. NDIS calls typically work out
such that you don’t need to post to a low-IRQL thread; typically you
are called in a context where the IRQL matches the NDIS calls you’re
likely going to need.
Look at NdisScheduleWorkItem. It may make your life a lot easier.
Work items run at PASSIVE_LEVEL.
I’d try to re-design to eliminate the locks if possible, and I’d
definitely think about using work items instead of a dedicated system
thread unless you’re doing long-running things.
Which DDI’s do you need to call at low IRQL?
-Steve
On Jun 4, 2007, at 12:17 PM, Michael Grimes wrote:
My scheduler thread is started in DriverEntry using
PsCreateSystemThread. What IRQL will this thread run at? My issue
here is making sure I do not make any system calls at an improper
IRQL so as to not cause a BSOD. Thanks…-----Original Message-----
> From: Steve Dispensa
>> Sent: Jun 4, 2007 12:41 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] NDIS IM Thread Locking
>>
>> Can you synchronize with purely interlocked operations? The CPU
>> instruction-based ones don’t touch IRQL. (The ones that take a spin
>> lock do, of course, although it’s done differently.)
>>
>> You want to be careful importing non-NDIS functions in your driver if
>> you’re going to get it signed. I can’t seem to find the forbidden
>> imports list on a quick Google search, but it’s out there somewhere.
>>
>> You should try with spin locks and profile to see if this really
>> matters. I bet it doesn’t. Or did you have some other reason for
>> wanting to stay at < DISPATCH_LEVEL?
>>
>> -sd
>>
>> On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
>>
>>> I have a scheduler thread in my NDIS IM driver. I need to have
>>> some sort of mutex like locking between threads when adding/
>>> removing from my scheduler list. Is there a safe way to lock
>>> without raising the IRQL?
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at http://
>>> www.osronline.com/article.cfm?id=256
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at http://
>> www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
I would love to eliminate the locks but I have the age old problem of 2 threads accessing the
same list - both potentially adding and removing…
-----Original Message-----
From: Steve Dispensa
>Sent: Jun 4, 2007 1:45 PM
>To: Windows System Software Devs Interest List
>Subject: Re: [ntdev] NDIS IM Thread Locking
>
>You might want to be careful about what DDI’s you’re calling; many of
>them can make your driver un-signable. NDIS calls typically work out
>such that you don’t need to post to a low-IRQL thread; typically you
>are called in a context where the IRQL matches the NDIS calls you’re
>likely going to need.
>
>Look at NdisScheduleWorkItem. It may make your life a lot easier.
>Work items run at PASSIVE_LEVEL.
>
>I’d try to re-design to eliminate the locks if possible, and I’d
>definitely think about using work items instead of a dedicated system
>thread unless you’re doing long-running things.
>
>Which DDI’s do you need to call at low IRQL?
>
> -Steve
>
>On Jun 4, 2007, at 12:17 PM, Michael Grimes wrote:
>
>> My scheduler thread is started in DriverEntry using
>> PsCreateSystemThread. What IRQL will this thread run at? My issue
>> here is making sure I do not make any system calls at an improper
>> IRQL so as to not cause a BSOD. Thanks…
>>
>> -----Original Message-----
>>> From: Steve Dispensa
>>> Sent: Jun 4, 2007 12:41 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re: [ntdev] NDIS IM Thread Locking
>>>
>>> Can you synchronize with purely interlocked operations? The CPU
>>> instruction-based ones don’t touch IRQL. (The ones that take a spin
>>> lock do, of course, although it’s done differently.)
>>>
>>> You want to be careful importing non-NDIS functions in your driver if
>>> you’re going to get it signed. I can’t seem to find the forbidden
>>> imports list on a quick Google search, but it’s out there somewhere.
>>>
>>> You should try with spin locks and profile to see if this really
>>> matters. I bet it doesn’t. Or did you have some other reason for
>>> wanting to stay at < DISPATCH_LEVEL?
>>>
>>> -sd
>>>
>>> On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
>>>
>>>> I have a scheduler thread in my NDIS IM driver. I need to have
>>>> some sort of mutex like locking between threads when adding/
>>>> removing from my scheduler list. Is there a safe way to lock
>>>> without raising the IRQL?
>>>>
>>>> —
>>>> Questions? First check the Kernel Driver FAQ at http://
>>>> www.osronline.com/article.cfm?id=256
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at http://
>>> www.osronline.com/article.cfm?id=256
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at http://
>> www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
The start routine for a PsCreateSystemThread thread begins at IRQL ==
PASSIVE_LEVEL. You can, of course, raise the IRQL of the thread where
necessary, so long as that when you finally exit it with
PsTerminateSystemThread, it is executing at IRQL == PASSIVE_LEVEL again.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Michael Grimes” wrote in message news:xxxxx@ntdev…
> My scheduler thread is started in DriverEntry using PsCreateSystemThread.
> What IRQL will this thread run at? My issue here is making sure I do not
> make any system calls at an improper IRQL so as to not cause a BSOD.
> Thanks…
>
> -----Original Message-----
>>From: Steve Dispensa
>>Sent: Jun 4, 2007 12:41 PM
>>To: Windows System Software Devs Interest List
>>Subject: Re: [ntdev] NDIS IM Thread Locking
>>
>>Can you synchronize with purely interlocked operations? The CPU
>>instruction-based ones don’t touch IRQL. (The ones that take a spin
>>lock do, of course, although it’s done differently.)
>>
>>You want to be careful importing non-NDIS functions in your driver if
>>you’re going to get it signed. I can’t seem to find the forbidden
>>imports list on a quick Google search, but it’s out there somewhere.
>>
>>You should try with spin locks and profile to see if this really
>>matters. I bet it doesn’t. Or did you have some other reason for
>>wanting to stay at < DISPATCH_LEVEL?
>>
>> -sd
>>
>>On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
>>
>>> I have a scheduler thread in my NDIS IM driver. I need to have
>>> some sort of mutex like locking between threads when adding/
>>> removing from my scheduler list. Is there a safe way to lock
>>> without raising the IRQL?
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at http://
>>> www.osronline.com/article.cfm?id=256
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>>http://www.osronline.com/article.cfm?id=256
>>
>>To unsubscribe, visit the List Server section of OSR Online at
>>http://www.osronline.com/page.cfm?name=ListServer
>
>
In that case, use spin locks and profile to see if it matters.
-Steve
On Jun 4, 2007, at 1:30 PM, Michael Grimes wrote:
I would love to eliminate the locks but I have the age old problem
of 2 threads accessing the
same list - both potentially adding and removing…-----Original Message-----
> From: Steve Dispensa
>> Sent: Jun 4, 2007 1:45 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] NDIS IM Thread Locking
>>
>> You might want to be careful about what DDI’s you’re calling; many of
>> them can make your driver un-signable. NDIS calls typically work out
>> such that you don’t need to post to a low-IRQL thread; typically you
>> are called in a context where the IRQL matches the NDIS calls you’re
>> likely going to need.
>>
>> Look at NdisScheduleWorkItem. It may make your life a lot easier.
>> Work items run at PASSIVE_LEVEL.
>>
>> I’d try to re-design to eliminate the locks if possible, and I’d
>> definitely think about using work items instead of a dedicated system
>> thread unless you’re doing long-running things.
>>
>> Which DDI’s do you need to call at low IRQL?
>>
>> -Steve
>>
>> On Jun 4, 2007, at 12:17 PM, Michael Grimes wrote:
>>
>>> My scheduler thread is started in DriverEntry using
>>> PsCreateSystemThread. What IRQL will this thread run at? My issue
>>> here is making sure I do not make any system calls at an improper
>>> IRQL so as to not cause a BSOD. Thanks…
>>>
>>> -----Original Message-----
>>>> From: Steve Dispensa
>>>> Sent: Jun 4, 2007 12:41 PM
>>>> To: Windows System Software Devs Interest List
>>>>
>>>> Subject: Re: [ntdev] NDIS IM Thread Locking
>>>>
>>>> Can you synchronize with purely interlocked operations? The CPU
>>>> instruction-based ones don’t touch IRQL. (The ones that take a spin
>>>> lock do, of course, although it’s done differently.)
>>>>
>>>> You want to be careful importing non-NDIS functions in your
>>>> driver if
>>>> you’re going to get it signed. I can’t seem to find the forbidden
>>>> imports list on a quick Google search, but it’s out there
>>>> somewhere.
>>>>
>>>> You should try with spin locks and profile to see if this really
>>>> matters. I bet it doesn’t. Or did you have some other reason for
>>>> wanting to stay at < DISPATCH_LEVEL?
>>>>
>>>> -sd
>>>>
>>>> On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
>>>>
>>>>> I have a scheduler thread in my NDIS IM driver. I need to have
>>>>> some sort of mutex like locking between threads when adding/
>>>>> removing from my scheduler list. Is there a safe way to lock
>>>>> without raising the IRQL?
>>>>>
>>>>> —
>>>>> Questions? First check the Kernel Driver FAQ at http://
>>>>> www.osronline.com/article.cfm?id=256
>>>>>
>>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>>
>>>> —
>>>> Questions? First check the Kernel Driver FAQ at http://
>>>> www.osronline.com/article.cfm?id=256
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at http://
>>> www.osronline.com/article.cfm?id=256
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at http://
>> www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> Is there a safe way to lock without raising the IRQL?
Actually, all synchronization objects (apart from spinlock, of course) work this way…
The only question is whether you can afford them - you can use them if and only if the target code is guaranteed to run at IRQL < DISPATCH_LEVEL.
If you need to update just one variable, interlocked operation may be an option as well. Just make sure that you don’t use interlocked operations all the time - they can be expensive if you use them too often…
My scheduler thread is started in DriverEntry using PsCreateSystemThread. What
IRQL will this thread run at?
Think about it carefully, and you will understand it yourself…
If some thread runs at IRQL >= DISPATCH_LEVEL all the time, it will simply monopolize the CPU, because context switches cannot occur at elevated IRQL. Therefore, any thread in the system runs at IRQL==PASSIVE_LEVEL most of the time - it may run at elevated IRQL only for the very short periods of time during speed-critical operations (i.e. interrupt and DPC processing and operations
that are guarded by spinlocks). Hence, as far as your code is concerned, this thread will run at IRQL_PASSIVE_LEVEL, unless you raise IRQL (or call some buggy code that does so and “forgets” to restore it before returning conrol to your code) …
Anton Bassov
> I would love to eliminate the locks but I have the age old problem
of 2 threads accessing the
> same list - both potentially adding and removing…
Not sure whether it’s relevant, but JIC: have you thought about lockless operations?
Alexandrescu wrote about them quite a lot in CUJ or DrDobbs or whatever.
Google for “Alexandrescu lockless” brings up lockless queues almost immediately.
IIRC, the idea is exploit one op of the interlocked family, namely, InterlockedCompareExchange, to add/remove elements of a queue atomically.
Interlocked are expensive, as someone has noted, but - if applicable in your case - still much cheaper than (almost) anything else and can be applied at any IRQL.
-------------- Original message --------------
From: Steve Dispensa
> In that case, use spin locks and profile to see if it matters.
>
> -Steve
>
> On Jun 4, 2007, at 1:30 PM, Michael Grimes wrote:
>
> > I would love to eliminate the locks but I have the age old problem
> > of 2 threads accessing the
> > same list - both potentially adding and removing…
> >
> >
> > -----Original Message-----
> >> From: Steve Dispensa
> >> Sent: Jun 4, 2007 1:45 PM
> >> To: Windows System Software Devs Interest List
> >> Subject: Re: [ntdev] NDIS IM Thread Locking
> >>
> >> You might want to be careful about what DDI’s you’re calling; many of
> >> them can make your driver un-signable. NDIS calls typically work out
> >> such that you don’t need to post to a low-IRQL thread; typically you
> >> are called in a context where the IRQL matches the NDIS calls you’re
> >> likely going to need.
> >>
> >> Look at NdisScheduleWorkItem. It may make your life a lot easier.
> >> Work items run at PASSIVE_LEVEL.
> >>
> >> I’d try to re-design to eliminate the locks if possible, and I’d
> >> definitely think about using work items instead of a dedicated system
> >> thread unless you’re doing long-running things.
> >>
> >> Which DDI’s do you need to call at low IRQL?
> >>
> >> -Steve
> >>
> >> On Jun 4, 2007, at 12:17 PM, Michael Grimes wrote:
> >>
> >>> My scheduler thread is started in DriverEntry using
> >>> PsCreateSystemThread. What IRQL will this thread run at? My issue
> >>> here is making sure I do not make any system calls at an improper
> >>> IRQL so as to not cause a BSOD. Thanks…
> >>>
> >>> -----Original Message-----
> >>>> From: Steve Dispensa
> >>>> Sent: Jun 4, 2007 12:41 PM
> >>>> To: Windows System Software Devs Interest List
> >>>>
> >>>> Subject: Re: [ntdev] NDIS IM Thread Locking
> >>>>
> >>>> Can you synchronize with purely interlocked operations? The CPU
> >>>> instruction-based ones don’t touch IRQL. (The ones that take a spin
> >>>> lock do, of course, although it’s done differently.)
> >>>>
> >>>> You want to be careful importing non-NDIS functions in your
> >>>> driver if
> >>>> you’re going to get it signed. I can’t seem to find the forbidden
> >>>> imports list on a quick Google search, but it’s out there
> >>>> somewhere.
> >>>>
> >>>> You should try with spin locks and profile to see if this really
> >>>> matters. I bet it doesn’t. Or did you have some other reason for
> >>>> wanting to stay at < DISPATCH_LEVEL?
> >>>>
> >>>> -sd
> >>>>
> >>>> On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
> >>>>
> >>>>> I have a scheduler thread in my NDIS IM driver. I need to have
> >>>>> some sort of mutex like locking between threads when adding/
> >>>>> removing from my scheduler list. Is there a safe way to lock
> >>>>> without raising the IRQL?
> >>>>>
> >>>>> —
> >>>>> Questions? First check the Kernel Driver FAQ at http://
> >>>>> www.osronline.com/article.cfm?id=256
> >>>>>
> >>>>> To unsubscribe, visit the List Server section of OSR Online at
> >>>>> http://www.osronline.com/page.cfm?name=ListServer
> >>>>
> >>>>
> >>>> —
> >>>> Questions? First check the Kernel Driver FAQ at http://
> >>>> www.osronline.com/article.cfm?id=256
> >>>>
> >>>> To unsubscribe, visit the List Server section of OSR Online at
> >>>> http://www.osronline.com/page.cfm?name=ListServer
> >>>
> >>>
> >>> —
> >>> Questions? First check the Kernel Driver FAQ at http://
> >>> www.osronline.com/article.cfm?id=256
> >>>
> >>> To unsubscribe, visit the List Server section of OSR Online at
> >>> http://www.osronline.com/page.cfm?name=ListServer
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at http://
> >> www.osronline.com/article.cfm?id=256
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://
> > www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
You can do this based on only “lock cmpxchg8”, for 32-bit CPUs, using
what basically boils down to a state machine. It’s not hard to wrap
your brain around the idea if you have a few hours to mess with it,
but it’s error-prone until you get good at it. The cost of the bus
lock is also arguably important (there are a number of cases in which
it’s fast, subject to cache line alignment, etc.), vs. the time it
takes to change IRQL.
I wrote a lock-free doubly-linked list last year based on this
principle, and it does work - it took 3 states IIRC, and the idea is
that you use the interlocked op to signal where you are in the
process (modify back link, modify front link, etc…). The key to
making it non-blocking is that every thread has to be able to help
every other thread make forward progress; otherwise there are
priority inversion deadlocks and such.
Anyway, all this is really thinking too much. Code it with a spin
lock and profile.
-Steve
On Jun 4, 2007, at 4:04 PM, xxxxx@comcast.net wrote:
> I would love to eliminate the locks but I have the age old problem
> of 2 threads accessing the
> same list - both potentially adding and removing…
Not sure whether it’s relevant, but JIC: have you thought about
lockless operations?Alexandrescu wrote about them quite a lot in CUJ or DrDobbs or
whatever.Google for “Alexandrescu lockless” brings up lockless queues almost
immediately.IIRC, the idea is exploit one op of the interlocked family, namely,
InterlockedCompareExchange, to add/remove elements of a queue
atomically.Interlocked are expensive, as someone has noted, but - if
applicable in your case - still much cheaper than (almost) anything
else and can be applied at any IRQL.-------------- Original message --------------
From: Steve Dispensa
>
> > In that case, use spin locks and profile to see if it matters.
> >
> > -Steve
> >
> > On Jun 4, 2007, at 1:30 PM, Michael Grimes wrote:
> >
> > > I would love to eliminate the locks but I have the age old problem
> > > of 2 threads accessing the
> > > same list - both potentially adding and removing…
> > >
> > >
> > > -----Original Message-----
> > >> From: Steve Dispensa
> > >> Sent: Jun 4, 2007 1:45 PM
> > >> To: Windows System Software Devs Interest List
> > >> Subject: Re: [ntdev] NDIS IM Thread Locking
> > >>
> > >> You might want to be careful about what DDI’s you’re calling;
> man y of
> > >> them can make your driver un-signable. NDIS calls typically
> work out
> > >> such that you don’t need to post to a low-IRQL thread;
> typically you
> > >> are called in a context where the IRQL matches the NDIS calls
> you’re
> > >> likely going to need.
> > >>
> > >> Look at NdisScheduleWorkItem. It may make your life a lot easier.
> > >> Work items run at PASSIVE_LEVEL.
> > >>
> > >> I’d try to re-design to eliminate the locks if possible, and I’d
> > >> definitely think about using work items instead of a dedicated
> system
> > >> thread unless you’re doing long-running things.
> > >>
> > >> Which DDI’s do you need to call at low IRQL?
> > >>
> > >> -Steve
> > >>
> > >> On Jun 4, 2007, at 12:17 PM, Michael Grimes wrote:
> > >>
> > >>> My scheduler thread is started in DriverEntry using
> > >>> PsCreateSystemThread. What IRQL will this thread run at? My
> issue
> > >>> here is making sure I do not make any system calls at an
> improper
> > >>> IRQL so as to not cause a BSOD. Thanks…
> > >>>
> > >>> -----Original Message-----
> > >>>> From: Steve Dispensa
> > >>>> Sent: Jun 4, 2007 12:41 PM
> > >>>> To: Windows System Software Devs Interest List
> > >>>>
> > >>>> Subject: Re: [ntdev] NDIS IM Thread Locking
> > >>>>
> > >>>> Can you synchronize with purely interlocked operations? The CPU
> > >>>> instruction-based ones don’t touch IRQL. (The ones that take
> a spin
> > >>>> lock do, of course, although it’s done differently.)
> > >>>>
> > >>>> Yo u want to be careful importing non-NDIS functions in your
> > >>>> driver if
> > >>>> you’re going to get it signed. I can’t seem to find the
> forbidden
> > >>>> imports list on a quick Google search, but it’s out there
> > >>>> somewhere.
> > >>>>
> > >>>> You should try with spin locks and profile to see if this
> really
> > >>>> matters. I bet it doesn’t. Or did you have some other reason
> for
> > >>>> wanting to stay at < DISPATCH_LEVEL?
> > >>>>
> > >>>> -sd
> > >>>>
> > >>>> On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
> > >>>>
> > >>>>> I have a scheduler thread in my NDIS IM driver. I need to have
> > >>>>> some sort of mutex like locking between threads when adding/
> > >>>>> removing fr om my scheduler list. Is there a safe way to lock
> > >>>>> without raising the IRQL?
> > >>>>>
> > >>>>> —
> > >>>>> Questions? First check the Kernel Driver FAQ at http://
> > >>>>> www.osronline.com/article.cfm?id=256
> > >>>>>
> > >>>>> To unsubscribe, visit the List Server section of OSR Online at
> > >>>>> http://www.osronline.com/page.cfm?name=ListServer
> > >>>>
> > >>>>
> > >>>> —
> > >>>> Questions? First check the Kernel Driver FAQ at http://
> > >>>> www.osronline.com/article.cfm?id=256
> > >>>>
> > >>>> To unsubscribe, visit the List Server section of OSR Online at
> > >>>> http://www.osronline.com/page.cfm?name=ListServer
> > >>>
> > >>>
> > >>> —
> > >>> Questions? First check the Kernel Driver FAQ at http://
> > >>> www.osronline.com/article.cfm?id=256
> > >>>
> > >>> To unsubscribe, visit the List Server section of OSR Online at
> > >>> http://www.osronline.com/page.cfm?name=ListServer
> > >>
> > >>
> > >> —
> > >> Questions? First check the Kernel Driver FAQ at http://
> > >> www.osronline.com/article.cfm?id=256
> > >>
> > >> To unsubscribe, visit the List Server section of OSR Online at
> > >> http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://
> > > www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?na me=ListServer
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Steve,
I wrote a lock-free doubly-linked list last year based on this principle, and it does work - it took 3 > states IIRC, and the idea is that you use the interlocked op to signal where you are in the
process (modify back link, modify front link, etc…). The key to making it non-blocking
is that every thread has to be able to help every other thread make forward progress; otherwise > there are priority inversion deadlocks and such.
As an intellectual challenge, I find it really exciting - I just love doing things like that in my spare time. However, probably it is not so good idea to use it in real-life projects, at least when someone has to maintain/reuse/modify your code…
Anton Bassov
An excellent point.
On Jun 4, 2007, at 6:57 PM, xxxxx@hotmail.com wrote:
Steve,
> I wrote a lock-free doubly-linked list last year based on this
> principle, and it does work - it took 3 > states IIRC, and the
> idea is that you use the interlocked op to signal where you are
> in the
> process (modify back link, modify front link, etc…). The key to
> making it non-blocking
> is that every thread has to be able to help every other thread
> make forward progress; otherwise > there are priority inversion
> deadlocks and such.As an intellectual challenge, I find it really exciting - I just
love doing things like that in my spare time. However, probably it
is not so good idea to use it in real-life projects, at least when
someone has to maintain/reuse/modify your code…Anton Bassov
Questions? First check the Kernel Driver FAQ at http://
www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Anyway, all this is really thinking too much.
No such thing exists:-)
From time to time a job should be fun, that’s what lockless queues are for:-)
And yes, I missed the point about a 8-byte op for a 4-byte box, looks like this is important.
To the OP:
Actually, Steve is right, as long as the purpose is not an intellectual excersise but regular salary:
Code it with a spin lock and profile.
-------------- Original message --------------
From: Steve Dispensa
> You can do this based on only “lock cmpxchg8”, for 32-bit CPUs, using
> what basically boils down to a state machine. It’s not hard to wrap
> your brain around the idea if you have a few hours to mess with it,
> but it’s error-prone until you get good at it. The cost of the bus
> lock is also arguably important (there are a number of cases in which
> it’s fast, subject to cache line alignment, etc.), vs. the time it
> takes to change IRQL.
>
> I wrote a lock-free doubly-linked list last year based on this
> principle, and it does work - it took 3 states IIRC, and the idea is
> that you use the interlocked op to signal where you are in the
> process (modify back link, modify front link, etc…). The key to
> making it non-blocking is that every thread has to be able to help
> every other thread make forward progress; otherwise there are
> priority inversion deadlocks and such.
>
> Anyway, all this is really thinking too much. Code it with a spin
> lock and profile.
>
> -Steve
>
> On Jun 4, 2007, at 4:04 PM, xxxxx@comcast.net wrote:
>
> > > I would love to eliminate the locks but I have the age old problem
> > > of 2 threads accessing the
> > > same list - both potentially adding and removing…
> > Not sure whether it’s relevant, but JIC: have you thought about
> > lockless operations?
> >
> > Alexandrescu wrote about them quite a lot in CUJ or DrDobbs or
> > whatever.
> >
> > Google for “Alexandrescu lockless” brings up lockless queues almost
> > immediately.
> >
> > IIRC, the idea is exploit one op of the interlocked family, namely,
> > InterlockedCompareExchange, to add/remove elements of a queue
> > atomically.
> >
> > Interlocked are expensive, as someone has noted, but - if
> > applicable in your case - still much cheaper than (almost) anything
> > else and can be applied at any IRQL.
> >
> > -------------- Original message --------------
> > From: Steve Dispensa
> >
> > > In that case, use spin locks and profile to see if it matters.
> > >
> > > -Steve
> > >
> > > On Jun 4, 2007, at 1:30 PM, Michael Grimes wrote:
> > >
> > > > I would love to eliminate the locks but I have the age old problem
> > > > of 2 threads accessing the
> > > > same list - both potentially adding and removing…
> > > >
> > > >
> > > > -----Original Message-----
> > > >> From: Steve Dispensa
> > > >> Sent: Jun 4, 2007 1:45 PM
> > > >> To: Windows System Software Devs Interest List
> > > >> Subject: Re: [ntdev] NDIS IM Thread Locking
> > > >>
> > > >> You might want to be careful about what DDI’s you’re calling;
> > man y of
> > > >> them can make your driver un-signable. NDIS calls typically
> > work out
> > > >> such that you don’t need to post to a low-IRQL thread;
> > typically you
> > > >> are called in a context where the IRQL matches the NDIS calls
> > you’re
> > > >> likely going to need.
> > > >>
> > > >> Look at NdisScheduleWorkItem. It may make your life a lot easier.
> > > >> Work items run at PASSIVE_LEVEL.
> > > >>
> > > >> I’d try to re-design to eliminate the locks if possible, and I’d
> > > >> definitely think about using work items instead of a dedicated
> > system
> > > >> thread unless you’re doing long-running things.
> > > >>
> > > >> Which DDI’s do you need to call at low IRQL?
> > > >>
> > > >> -Steve
> > > >>
> > > >> On Jun 4, 2007, at 12:17 PM, Michael Grimes wrote:
> > > >>
> > > >>> My scheduler thread is started in DriverEntry using
> > > >>> PsCreateSystemThread. What IRQL will this thread run at? My
> > issue
> > > >>> here is making sure I do not make any system calls at an
> > improper
> > > >>> IRQL so as to not cause a BSOD. Thanks…
> > > >>>
> > > >>> -----Original Message-----
> > > >>>> From: Steve Dispensa
> > > >>>> Sent: Jun 4, 2007 12:41 PM
> > > >>>> To: Windows System Software Devs Interest List
> > > >>>>
> > > >>>> Subject: Re: [ntdev] NDIS IM Thread Locking
> > > >>>>
> > > >>>> Can you synchronize with purely interlocked operations? The CPU
> > > >>>> instruction-based ones don’t touch IRQL. (The ones that take
> > a spin
> > > >>>> lock do, of course, although it’s done differently.)
> > > >>>>
> > > >>>> Yo u want to be careful importing non-NDIS functions in your
> > > >>>> driver if
> > > >>>> you’re going to get it signed. I can’t seem to find the
> > forbidden
> > > >>>> imports list on a quick Google search, but it’s out there
> > > >>>> somewhere.
> > > >>>>
> > > >>>> You should try with spin locks and profile to see if this
> > really
> > > >>>> matters. I bet it doesn’t. Or did you have some other reason
> > for
> > > >>>> wanting to stay at < DISPATCH_LEVEL?
> > > >>>>
> > > >>>> -sd
> > > >>>>
> > > >>>> On Jun 4, 2007, at 11:12 AM, xxxxx@onemain.com wrote:
> > > >>>>
> > > >>>>> I have a scheduler thread in my NDIS IM driver. I need to have
> > > >>>>> some sort of mutex like locking between threads when adding/
> > > >>>>> removing fr om my scheduler list. Is there a safe way to lock
> > > >>>>> without raising the IRQL?
> > > >>>>>
> > > >>>>> —
> > > >>>>> Questions? First check the Kernel Driver FAQ at http://
> > > >>>>> www.osronline.com/article.cfm?id=256
> > > >>>>>
> > > >>>>> To unsubscribe, visit the List Server section of OSR Online at
> > > >>>>> http://www.osronline.com/page.cfm?name=ListServer
> > > >>>>
> > > >>>>
> > > >>>> —
> > > >>>> Questions? First check the Kernel Driver FAQ at http://
> > > >>>> www.osronline.com/article.cfm?id=256
> > > >>>>
> > > >>>> To unsubscribe, visit the List Server section of OSR Online at
> > > >>>> http://www.osronline.com/page.cfm?name=ListServer
> > > >>>
> > > >>>
> > > >>> —
> > > >>> Questions? First check the Kernel Driver FAQ at http://
> > > >>> www.osronline.com/article.cfm?id=256
> > > >>>
> > > >>> To unsubscribe, visit the List Server section of OSR Online at
> > > >>> http://www.osronline.com/page.cfm?name=ListServer
> > > >>
> > > >>
> > > >> —
> > > >> Questions? First check the Kernel Driver FAQ at http://
> > > >> www.osronline.com/article.cfm?id=256
> > > >>
> > > >> To unsubscribe, visit the List Server section of OSR Online at
> > > >> http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at http://
> > > > www.osronline.com/article.cfm?id=256
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online at
> > > > http://www.osronline.com/page.cfm?na me=ListServer
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://
> > www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer