Windows Vista Tips

Windows Vista Tips > Newsgroups > Windows Vista Drivers > WDF Wait Lock Usage

Reply
Thread Tools Display Modes

WDF Wait Lock Usage

 
 
Murugesan
Guest
Posts: n/a

 
      11-10-2009
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
 
Reply With Quote
 
 
 
 
Murugesan
Guest
Posts: n/a

 
      11-11-2009
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" <> wrote in message
> news:41EC25C5-EC76-4620-ACA5-...
> > 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
>
>
>
>
> .
>

 
Reply With Quote
 
Doron Holan [MSFT]
Guest
Posts: n/a

 
      11-11-2009
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" <> wrote in message
news:333C145D-8881-4272-8C34-...
> 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" <> wrote in message
>> news:41EC25C5-EC76-4620-ACA5-...
>> > 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
>>
>>
>>
>>
>> .
>>

 
Reply With Quote
 
Murugesan
Guest
Posts: n/a

 
      11-13-2009
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" <> wrote in message
> news:333C145D-8881-4272-8C34-...
> > 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" <> wrote in message
> >> news:41EC25C5-EC76-4620-ACA5-...
> >> > 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
> >>
> >>
> >>
> >>
> >> .
> >>

> .
>

 
Reply With Quote
 
Doron Holan [MSFT]
Guest
Posts: n/a

 
      11-16-2009
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" <> wrote in message
news:023D6B4E-0868-479D-9854-...
> 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" <> wrote in message
>> news:333C145D-8881-4272-8C34-...
>> > 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" <> wrote in message
>> >> news:41EC25C5-EC76-4620-ACA5-...
>> >> > 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
>> >>
>> >>
>> >>
>> >>
>> >> .
>> >>

>> .
>>

 
Reply With Quote
 
Murugesan
Guest
Posts: n/a

 
      11-19-2009
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" <> wrote in message
> news:023D6B4E-0868-479D-9854-...
> > 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" <> wrote in message
> >> news:333C145D-8881-4272-8C34-...
> >> > 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" <> wrote in message
> >> >> news:41EC25C5-EC76-4620-ACA5-...
> >> >> > 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
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> .
> >> >>
> >> .
> >>

> .
>

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: WDF Wait Lock Usage Don Burn Windows Vista Drivers 0 11-10-2009 06:49 PM
svchost.exe memory usage vistauser Windows Vista Performance 3 01-05-2008 10:38 PM
The perfect HD Usage monitor Luca Villa Windows Vista Performance 5 08-22-2007 04:41 PM
CPU usage 100% ChrisJ Windows Vista Performance 20 02-20-2007 04:40 AM
Re: Purchase Now or Wait for Vista? Rick Rogers Windows Vista Installation 4 12-15-2006 07:03 PM



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59