WDF Wait Lock Usage

[Murugesan]

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

[Don Burn]

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" <Muru...@discussions.microsoft.com> wrote in message
news:41EC25C5-EC76-4620...@microsoft.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
>
>
>

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4593 (20091110) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Murugesan]

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:

> .
>

[Doron Holan [MSFT]]

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" <Muru...@discussions.microsoft.com> wrote in message

news:333C145D-8881-4272...@microsoft.com...

[Murugesan]

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:

> .
>

[Doron Holan [MSFT]]

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" <Muru...@discussions.microsoft.com> wrote in message

news:023D6B4E-0868-479D...@microsoft.com...

[Murugesan]

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:

> .
>