From: Roddy, Mark [Mark.Roddy@stratus.com] Sent: Friday, March 09, 2001 12:14 PM To: NT Developers Interest List Subject: [ntdev] RE: synchronization problem That will work fine as well, call it solution (3). However, as all you want to do is signal a kernel thread that it can resume execution, sending an IOCTL from user space so that an event can be signaled in kernel space seems to be a little excessive, unless you need to send this IO request anyhow (like to transfer data to kernel space.) I'd share the event between user mode and kernel mode and have the app set the event, as in solutions (A) and (B). Mark Roddy markr@hollistech.com www.hollistech.com 603 321 1032 WindowsNT Windows 2000 Consulting Services -----Original Message----- From: Matteo Pelati [mailto:matteo@dolce.it] Sent: Friday, March 09, 2001 11:34 AM To: NT Developers Interest List Subject: [ntdev] RE: synchronization problem Yes, that's very similar to waht i meant. Telling the truth I didn't think to share the event object between user and kernel mode. This is what i was thinking to do: - in my driver associate my event with an ioctl code and complete the IRP. At this point the app starts executing code. - wait on a dinamically allocated event in my driver - when the app completes its executin it sends an IOCTL down to my driver containing the ioctl code - in my dispatch routine receving the new ioctl i set the event so my km code can continue Matteo ----- Original Message ----- From: "Mark Roddy" To: "NT Developers Interest List" Sent: Friday, March 09, 2001 1:03 PM Subject: [ntdev] RE: synchronization problem > A) Have your user app include an event handle in the IOCTL. Go figure out > how to convert the process specific event handle into a KEVENT object you > can use in the kernel in an arbitrary process context. Your kernel thread > blocks on the event after completing the IRP, and your user app sets the > event when its task is complete. > > B) As each user thread needs no more than one event, you could also use > named events, which are easier to share between user mode and kernel mode > threads. Your user threads would 'register' with your driver with a separate > IOCTL providing the name of the named event specific to that thread. Your > driver could then use the documented DDK functions to open named events, and > would be responsible for correlating thread to event for your other IOCTL. > > Mark Roddy > Windows 2000/NT Consultant > Hollis Technology Solutions > info@hollistech.com > 603 321 1032 > www.hollistech.com > > > -----Original Message----- > > From: bounce-ntdev-311@lists.osr.com > > [mailto:bounce-ntdev-311@lists.osr.com]On Behalf Of Matteo Pelati > > Sent: Friday, March 09, 2001 5:19 AM > > To: NT Developers Interest List > > Subject: [ntdev] RE: synchronization problem > > > > > > Well, not really because I've to wait for the user mode function to > > complete. My KM thread needs to be blocked until my user mode function > > completes. I cannot continue in KM without the result coming from the UM > > app. > > > > I consodered the option of moving all the code to TCP/IP but that > > seems too > > much time consuming. And moreover i need to hook the UM app to > > the kernel... > > I need to get some packet sent to a protocol driver (TCP/IP) and manging > > them from a UM app. > > > > Thanks > > Matteo > > ----- Original Message ----- > > From: "Vodicka, Michal" > > To: "NT Developers Interest List" > > Sent: Friday, March 09, 2001 1:33 AM > > Subject: [ntdev] RE: synchronization problem > > > > > > > It should work if you're running on passive level but remember you're > > > blocking original requestor thread. In some cases it can cause funny > > > deadlocks if continue in user mode. > > > > > > Other possibility: can you return pending status to original > > requestor and > > > complete request later? If so, you don't need to wait, just send data to > > > your app, return pending and complete processing when receive IRP with > > > results. > > > > > > BTW, wouldn't be easier to move all user mode code to your driver? I > > always > > > prefer this solution... > > > > > > Best regards, > > > > > > Michal Vodicka > > > Veridicom > > > (RKK - Skytale) > > > [WWW: http://www.veridicom.com , http://www.skytale.com] > > > > > > > ---------- > > > > From: Matteo Pelati[SMTP:matteo@dolce.it] > > > > Reply To: NT Developers Interest List > > > > Sent: Friday, March 09, 2001 1:06 AM > > > > To: NT Developers Interest List > > > > Subject: [ntdev] RE: synchronization problem > > > > > > > > Ok. > > > > I've a packet of data in my driver. I received that packet with an > > > > IOCTL/TDI > > > > request. I've to process this packet, partly using kernel > > functions (in > > my > > > > driver) and partly using my application's functions. Now, suppose I've > > to > > > > pass that packet of data to my application up in user mode, > > so that the > > > > app > > > > can modify it and when it returns, depending how the packet has been > > > > modified it can follow different paths. I use a pending (more than one > > if > > > > necessary) to send data to user mode to my app...then I've to > > wait until > > > > my > > > > app completes the operation so i can receive the modified packet and > > > > continue processing. So, I will have to wait until my application's > > > > function > > > > modify the data and complete the operation...that is, complete the > > > > operation > > > > and send down an IOCTL -> so, I'll have to wait for an IOCTL from my > > app. > > > > My > > > > question is how do i do that? The only thing thet come up to my mind > > righ > > > > now is by creating an event object (I'm running at PASSIVE IRQL..so no > > > > problem) before sending the request to user mode, that wait on that > > event. > > > > When I will receive an IOCTL from the app, in my Dispatch > > function I can > > > > set > > > > the event to allow the code to continue...it should work... better > > ideas? > > > > > > > > Thanks > > > > Matteo > > > > > > > > ----- Original Message ----- > > > > From: "Vodicka, Michal" > > > > To: "NT Developers Interest List" > > > > Sent: Friday, March 09, 2001 12:43 AM > > > > Subject: [ntdev] RE: synchronization problem > > > > > > > > > > > > > It depends on the reason why and where you need wait. In some > > situations > > > > you > > > > > can just do nothing and continue processing when receive an IRP with > > > > > results. If you have a worker thread, you can wait for an event and > > set > > > > it > > > > > in dispatch function when receive results. All depends on actual > > > > conditions > > > > > (IRQL...), write more details. > > > > > > > > > > Best regards, > > > > > > > > > > Michal Vodicka > > > > > Veridicom > > > > > (RKK - Skytale) > > > > > [WWW: http://www.veridicom.com , http://www.skytale.com] > > > > > > > > > > --- > > > You are currently subscribed to ntdev as: matteo@dolce.it > > > To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com > > > > > > --- > > You are currently subscribed to ntdev as: mroddy@wattanuck.mv.com > > To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com > > > > > > > > --- > You are currently subscribed to ntdev as: matteo@dolce.it > To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com --- You are currently subscribed to ntdev as: Mark.Roddy@stratus.com To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com --- You are currently subscribed to ntdev as: GlennEverhart@FirstUSA.com To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com