WDF Wait Lock Usage
in [Device Drivers]
|
From: Doron Holan [MSFT] on 16 Nov 2009 16:06 there are no abstractions for these things b/c KMDF would add no value by abstracting them. you can certainly have your own thread and do what you like with it. with that said, why not use power managed queues to manage your idle state? that way you do not use a thread and you leverage KMDF's already tested idle code d -- This posting is provided "AS IS" with no warranties, and confers no rights. "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message news:023D6B4E-0868-479D-9854-34989F9FD0BB(a)microsoft.com... > Hi Doron, > > I agree with your suggestion. But I have a query here. I think WDF doesn't > encourage to create drivers which runs in its own thread context. Because > WDF > doesn't have framework functions for thread implementation, waiting for > event > & wakeup scenarios. > I need to develop a driver which has a separate core thread which will be > blocked while idle & unblocked while processing any requests queued to it. > From the discussion, i think that this driver cannot be implemented > as a framework based (using only WDF functions without any WDM > functionalities).Is it true ? > > Murugesan. > > "Doron Holan [MSFT]" wrote: > >> just use a KEVENT if you want thread wake up semantics. a WDFWAITLOC is >> meant as a passive level synchonrization mechanism to synchronize access >> to >> a resource (like a list) >> >> d >> >> -- >> >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >> >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message >> news:333C145D-8881-4272-8C34-C666FCF958AD(a)microsoft.com... >> > WdfWaitLockAcquire The sequence: >> > KeEnterCriticalRegion >> > KeWaitForSingleObject >> > >> > WdfWaitLockCreate KeInitializeEvent >> > >> > WdfWaitLockRelease The sequence: >> > KeSetEvent >> > KeLeaveCriticalRegion >> > >> > These are the WDM equivalents for WDF functionalities as per >> > Microsoft's >> > porting WDM to KMDF document. >> > My earlier question might be incorrect. I agree that >> > KeWaitForSingleObject() >> > does not put the thread into wait state unless the object is not >> > available, >> > as for the KEVENT is considered it can be initialized with non >> > signalled >> > state so that the kewaitforsingleobject(event, NULL) puts a thread into >> > wait >> > state until some other thread moves the event into signalled state. So >> > my >> > question here is can we acheive this similar operation with >> > WDFWAITLOCK. >> > In other words, we have an option to configure initial value of an >> > event >> > using KeInitializeEvent so that we could make KeWaitForSingleObject to >> > wait >> > for the event when it encounters first time(after KeInitializeEvent). >> > If >> > WDFWAITLOCK is an equivalent of KEVENT, then could we initialize the >> > state >> > of >> > lock object while creating lock using WdfWaitLockCreate so that >> > WdfWaitLockAcquire waits for the lock object when it encounters for the >> > first >> > time. >> > >> > "Don Burn" wrote: >> > >> >> I can't imagine why you would think it has anything to do with >> >> KEVENTS. >> >> Take a look at the various mutexs. Also, you are incorrect on >> >> KeWaitForSingleObject it does not put the thread into a wait state >> >> unless >> >> the object is not available. >> >> >> >> >> >> -- >> >> Don Burn (MVP, Windows DKD) >> >> Windows Filesystem and Driver Consulting >> >> Website: http://www.windrvr.com >> >> Blog: http://msmvps.com/blogs/WinDrvr >> >> Remove StopSpam to reply >> >> >> >> >> >> >> >> >> >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message >> >> news:41EC25C5-EC76-4620-ACA5-13F236770BF3(a)microsoft.com... >> >> > Hi all, >> >> > From the WDF documentation, WdfWaitLock is the replacement for >> >> > KEVENT(WDM). >> >> > So if a thread calls wdfwaitlockacquire() will it be put in wait >> >> > state >> >> > eventhough the lock object is available. >> >> > In other words, is wdfwaitlockacquire() & wdfwaitlockrelease() an >> >> > exact >> >> > replacement of Kewaitforsingleobject() & KeSetEvent() ? >> >> > >> >> > Thanks, >> >> > Murugesan >> >> > >> >> > __________ Information from ESET NOD32 Antivirus, version of virus >> >> > signature database 4593 (20091110) __________ >> >> > >> >> > The message was checked by ESET NOD32 Antivirus. >> >> > >> >> > http://www.eset.com >> >> > >> >> > >> >> > >> >> >> >> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> >> signature database 4593 (20091110) __________ >> >> >> >> The message was checked by ESET NOD32 Antivirus. >> >> >> >> http://www.eset.com >> >> >> >> >> >> >> >> >> >> . >> >> >> . >>
From: Murugesan on 19 Nov 2009 00:29
Thanks Doron. The core thread in my project shouldn't adhere to any OS, we are maintaining an abstraction with OS functionalities. So I couldn't use framework provided queues. But if framework provided queues provide a better efficiency than threads, then i'll use that definitely. Thanks again, Murugesan.S "Doron Holan [MSFT]" wrote: > there are no abstractions for these things b/c KMDF would add no value by > abstracting them. you can certainly have your own thread and do what you > like with it. with that said, why not use power managed queues to manage > your idle state? that way you do not use a thread and you leverage KMDF's > already tested idle code > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > news:023D6B4E-0868-479D-9854-34989F9FD0BB(a)microsoft.com... > > Hi Doron, > > > > I agree with your suggestion. But I have a query here. I think WDF doesn't > > encourage to create drivers which runs in its own thread context. Because > > WDF > > doesn't have framework functions for thread implementation, waiting for > > event > > & wakeup scenarios. > > I need to develop a driver which has a separate core thread which will be > > blocked while idle & unblocked while processing any requests queued to it. > > From the discussion, i think that this driver cannot be implemented > > as a framework based (using only WDF functions without any WDM > > functionalities).Is it true ? > > > > Murugesan. > > > > "Doron Holan [MSFT]" wrote: > > > >> just use a KEVENT if you want thread wake up semantics. a WDFWAITLOC is > >> meant as a passive level synchonrization mechanism to synchronize access > >> to > >> a resource (like a list) > >> > >> d > >> > >> -- > >> > >> This posting is provided "AS IS" with no warranties, and confers no > >> rights. > >> > >> > >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > >> news:333C145D-8881-4272-8C34-C666FCF958AD(a)microsoft.com... > >> > WdfWaitLockAcquire The sequence: > >> > KeEnterCriticalRegion > >> > KeWaitForSingleObject > >> > > >> > WdfWaitLockCreate KeInitializeEvent > >> > > >> > WdfWaitLockRelease The sequence: > >> > KeSetEvent > >> > KeLeaveCriticalRegion > >> > > >> > These are the WDM equivalents for WDF functionalities as per > >> > Microsoft's > >> > porting WDM to KMDF document. > >> > My earlier question might be incorrect. I agree that > >> > KeWaitForSingleObject() > >> > does not put the thread into wait state unless the object is not > >> > available, > >> > as for the KEVENT is considered it can be initialized with non > >> > signalled > >> > state so that the kewaitforsingleobject(event, NULL) puts a thread into > >> > wait > >> > state until some other thread moves the event into signalled state. So > >> > my > >> > question here is can we acheive this similar operation with > >> > WDFWAITLOCK. > >> > In other words, we have an option to configure initial value of an > >> > event > >> > using KeInitializeEvent so that we could make KeWaitForSingleObject to > >> > wait > >> > for the event when it encounters first time(after KeInitializeEvent). > >> > If > >> > WDFWAITLOCK is an equivalent of KEVENT, then could we initialize the > >> > state > >> > of > >> > lock object while creating lock using WdfWaitLockCreate so that > >> > WdfWaitLockAcquire waits for the lock object when it encounters for the > >> > first > >> > time. > >> > > >> > "Don Burn" wrote: > >> > > >> >> I can't imagine why you would think it has anything to do with > >> >> KEVENTS. > >> >> Take a look at the various mutexs. Also, you are incorrect on > >> >> KeWaitForSingleObject it does not put the thread into a wait state > >> >> unless > >> >> the object is not available. > >> >> > >> >> > >> >> -- > >> >> Don Burn (MVP, Windows DKD) > >> >> Windows Filesystem and Driver Consulting > >> >> Website: http://www.windrvr.com > >> >> Blog: http://msmvps.com/blogs/WinDrvr > >> >> Remove StopSpam to reply > >> >> > >> >> > >> >> > >> >> > >> >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > >> >> news:41EC25C5-EC76-4620-ACA5-13F236770BF3(a)microsoft.com... > >> >> > Hi all, > >> >> > From the WDF documentation, WdfWaitLock is the replacement for > >> >> > KEVENT(WDM). > >> >> > So if a thread calls wdfwaitlockacquire() will it be put in wait > >> >> > state > >> >> > eventhough the lock object is available. > >> >> > In other words, is wdfwaitlockacquire() & wdfwaitlockrelease() an > >> >> > exact > >> >> > replacement of Kewaitforsingleobject() & KeSetEvent() ? > >> >> > > >> >> > Thanks, > >> >> > Murugesan > >> >> > > >> >> > __________ Information from ESET NOD32 Antivirus, version of virus > >> >> > signature database 4593 (20091110) __________ > >> >> > > >> >> > The message was checked by ESET NOD32 Antivirus. > >> >> > > >> >> > http://www.eset.com > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> __________ Information from ESET NOD32 Antivirus, version of virus > >> >> signature database 4593 (20091110) __________ > >> >> > >> >> The message was checked by ESET NOD32 Antivirus. > >> >> > >> >> http://www.eset.com > >> >> > >> >> > >> >> > >> >> > >> >> . > >> >> > >> . > >> > . > |