Date: Fri, 13 Dec 2002 10:54:45 -0800 (PST)
From: Nate Lawson <nate@root.org>
To: Yar Tikhiy <yar@freebsd.org>
Cc: freebsd-scsi@freebsd.org
Subject: Re: {da,sa,...}open bug?
Message-ID: <Pine.BSF.4.21.0212131049550.36778-100000@root.org>
In-Reply-To: <20021212215655.A92315@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Dec 2002, Yar Tikhiy wrote: > On Tue, Dec 10, 2002 at 01:23:59PM -0800, Nate Lawson wrote: > > Here is what would happen with your patch: > > > > open() > > 1. lock -- refcount +1, get lock, refcount -1 > > 2. [open code runs] > > 3. acquire -- refcount +1 > > > > All throughout step 2, periph could disappear if another proc calls > > release. > > I see your point, but your scenario isn't exactly what would happen, to my mind. > If periph weren't currently locked, the refcount would change as follows: > 1. lock -- refcount +1, get lock > 2. [open code runs], refcount >0 > 3. acquire -- refcount +1 > 4. unlock -- refcount -1 > > As you may see, even if cam_periph_acquire() were called lately, > right before cam_periph_unlock(), refcount would never drop below 1. Yes, you are correct. I am still uncomfortable with moving acquire() to the end, depending on the side effect of it staying inside a lock/unlock scope. We may want to push down the locks later to only encapsulate a small portion of shared access routines and that would change this assumption. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0212131049550.36778-100000>