Re: Oney's Book, HandleQueryStop(): Why is there no race condition?
From: Mark Roddy (markr_at_hollistech.com)
Date: 05/09/04
- Next message: Mark Roddy: "Re: software raid0/striping on C: ?"
- Previous message: Mark Roddy: "Re: FDO created too late for new devices"
- In reply to: Bill McKenzie: "Re: Oney's Book, HandleQueryStop(): Why is there no race condition?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 9 May 2004 11:41:57 -0400
Over on the storage side of things, those of us with multipath storage
drivers (two paths to one disk) have to deal with this race condition on a
regular basis. We want to allow Q-remove or Q-stop on one path if another
path is available, but we want to fail the query if there is no other
available path. As 'available path' is an asynchronous state(1), managing
this is a bit tricky. The simplest approach is to just deny the query.
Unfortunately this results in the hideous 'reboot required' popup anytime a
new device instance enters the system. Other less conservative approaches
allow the query but leave the system vulnerable as the race condition cannot
be eliminated.
(1) for example somebody pulls a hotplug disk out of its slot.
-- ===================== Mark Roddy Windows 2003/XP/2000 Consulting Hollis Technology Solutions 603-321-1032 www.hollistech.com markr@hollistech.com "Bill McKenzie" <bill.mckenzie@nospam.conexant.com> wrote in message news:eIIHcMLNEHA.556@tk2msftngp13.phx.gbl... > > If there is need to stop the device, the driver should be > > able to stop it from any state? > > Not true or there would be no reason to allow for the rejection of a stop > through the query. Example: the best I can think of at the moment is a data > collection or frame grabber type device in an industrial setting which does > not wish to allow stops while (lengthy) data transfers are in progress. > This would seem a perfectly valid instance, albeit somewhat rare, in which > to reject a stop query. > > There are probably plenty of industrial devices which take a significant > amount of time to stop once set in motion, although a really good example > escapes me at the moment. > > -- > Bill McKenzie > Software Engineer - Prism 802.11 Wireless Solutions > Conexant Systems, Inc. > > > "Pavel A." <pavel_a@geeklife.com> wrote in message > news:O0FK2RGNEHA.2736@TK2MSFTNGP11.phx.gbl... > > Sorry for jumping in... > > but what exactly means "non-stoppable state"? > > If there is need to stop the device, the driver should be > > able to stop it from any state? > > > > Regards, > > --PA > > > > > > "Bill McKenzie" <bill.mckenzie@nospam.conexant.com> wrote in message > > news:OWFNKV4MEHA.3572@tk2msftngp13.phx.gbl... > > > Good catch! That is fairly subtle. > > > > > > -- > > > Bill McKenzie > > > Software Engineer - Prism 802.11 Wireless Solutions > > > Conexant Systems, Inc. > > > > > > > > > "Spiro Trikaliotis" <nntp+200405@trikaliotis.net> wrote in message > > > news:slrnc9k439.1mj.nntp+200405@news.trikaliotis.net... > > >> Hello Walter, > > >> > > >> Walter Oney <waltoney@oneysoft.com> wrote: > > >> > > >> > I don't see how to solve the problem of StartNextPacket starting an > > >> > IRP that will put the device into the non-stoppable state you've > > >> > posited without doing something like you've suggested. > > >> > > >> Ok, thank you for your help! > > >> > > >> Kind regards, > > >> Spiro. > > >> > > >> -- > > >> Spiro R. Trikaliotis > > >> http://www.trikaliotis.net/ > > > > > > > > > > > >
- Next message: Mark Roddy: "Re: software raid0/striping on C: ?"
- Previous message: Mark Roddy: "Re: FDO created too late for new devices"
- In reply to: Bill McKenzie: "Re: Oney's Book, HandleQueryStop(): Why is there no race condition?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
