Developer Forum

One user-mode thread and one kernel thread. they need to access a
shared resource exclusively. so i think i need a mutex, but i didn't
find a way to share a mutex object between kernel and user-mode. i'm
thinking of the following ways:
1. use event object.
create an auto-clearing event object in the user-mode thread. tell the
kernel thread about the user-mode handle of the event object. in the
context of the user-mode thread the driver can call
ObReferenceObjectByHandle to get a pointer to the kernel event object.
the event object is initialized to signaled state. either of the
threads performs a wait on it to acquire the ownership of the shared
resource. after using the resource set the event to signaled state
again.

2. use semaphore object.
create an binary semaphore object in the user-mode thread. tell the
driver about the user-mode handle of the semaphore. in the context of
the user-mode thread the driver can call ObReferenceObjectByHandle to
get a pointer to the kernel semaphore object. either of the threads
performs a wait on the semaphore to acquire the ownership of the shared
resource. after using the resource release the semaphore.

My questions:
1. Are these two methods workable?
2. Are there any other methods to do this?
3. Is the first method SMP safe?
4. DDK says binary semaphore is similiar to mutex object. But it
doesn't have built-in protection against deadlocks in SMP environment.
What does this mean? If i use binary semaphore as mutex, what troubles
will i suffer from on a dual-core CPU??

thanks!

I would suggest you to consider using IOCTLs instead of shared memory. This
means - moving to "request-response" paradigm and send IOCTLs to the driver
with the request data. The driver will answer with the response data.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
XXXX@XXXXX.COM
http://www.yqcomputer.com/

You have a major security hole and problem. If your application has to
follow "the rules" then anyone who can open your driver without following
"the rules" can crash the system. Sharing anything between a driver and an
application is a bad idea. Change you model to use IOCTL's and share
nothing.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

Thanks for the sugesstions.
But would you tell me how mush the performance lost would be if i use
IOCTLs instead of shared memory?
In my work, I need to exchange data blocks very frequently between r0
and r3.

Another question is:
If my driver needs to notify the user-mode application that there is
data up-coming. how should it do it? (Since one of the suggestion said
that sharing anything between ... is a bad idea)
i used an event shared by the application and the driver. the driver
will signal the event if it has data to pass to the applicaiton. then
the application will get the data by IOCTL

What is "very frequently" in your understanding?

50Mbps

Issue an overlapped IOCTL with the buffer (use DIRECT variant) and have the
driver pend it until it has data. Then the driver completes the request, and
the application gets the data.

thanks for the hint!

do i have to set a cancel-routine for the IRPs?

You should support cancel on the IRP's, otherwise there can be real pain.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply