Re: Sharing a Semaphore with a application.
- From: "Don Burn" <burn@xxxxxxxxxxxxxxxx>
- Date: Tue, 10 Jan 2006 13:07:41 -0500
So have an IOCTL you call instead of the semaphore and have the semaphore in
the kernel, the cost of the kernel transition is going to be the big ticket
item, the cost of doing this with an IOCTL versus calling into the kernel
for a wait for the event will be noise. And as Doron pointed out there are
advantages.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
"Frank The Tank" <FrankTheTank@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:82FA9F5C-7445-43F5-AEA8-C9B0AD05B62A@xxxxxxxxxxxxxxxx
> Thanks Doron
> Multiple I/O req. would not work for me in this application.This event is
> my
> way of getting a hardware interupt up as a trigger for an application
> thread
> to do its job. It is a continous interupt happening sometimes over 500
> times
> a minute. This worked very good until I pushed the system so that every
> once
> in a while the app. thread took to long and an event trigger was lost
> forever. A semaphore would of been a easy way to have the thread catch up
> (
> keeping a buffer at the end of a fiber cable at the correct level). I want
> to
> find a way to do this without polling the device.
>
.
- References:
- Re: Sharing a Semaphore with a application.
- From: Doron Holan [MS]
- Re: Sharing a Semaphore with a application.
- Prev by Date: Re: hooking api problem
- Next by Date: Limited on METHOD_BUFFERED
- Previous by thread: Re: Sharing a Semaphore with a application.
- Next by thread: Re: Sharing a Semaphore with a application.
- Index(es):
Relevant Pages
|
