Date: Fri, 11 Aug 2006 12:49:44 -0400 From: John Baldwin <jhb@freebsd.org> To: Divacky Roman <xdivac02@stud.fit.vutbr.cz> Cc: Roman Divacky <rdivacky@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org>, Robert Watson <rwatson@freebsd.org> Subject: Re: PERFORCE change 103633 for review Message-ID: <200608111249.44686.jhb@freebsd.org> In-Reply-To: <20060811121314.GA85207@stud.fit.vutbr.cz> References: <200608111110.k7BBAxIO059339@repoman.freebsd.org> <20060811124027.K45647@fledge.watson.org> <20060811121314.GA85207@stud.fit.vutbr.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 11 August 2006 08:13, Divacky Roman wrote: > On Fri, Aug 11, 2006 at 12:42:50PM +0100, Robert Watson wrote: > > On Fri, 11 Aug 2006, Roman Divacky wrote: > > > > >http://perforce.freebsd.org/chv.cgi?CH=103633 > > > > > >Change 103633 by rdivacky@rdivacky_witten on 2006/08/11 11:10:09 > > > > > > Giantify futex code - this is necessary because the futex code is > > > expected to be atomic. > > > I need to assure the atomicity. I am using Giant because its > > > sleepable mutex. I hope > > > someone will point me to some other better solution. > > > > Giant is not "sleepable" in the same sense that sx locks, lockmgr locks, > > etc, are. Normally "sleepable" means that the lock can be held across a > > sleep of potentially unbounded length, such as msleep(), tsleep(), > > cv_wait(), etc. Giant is automatically dropped by the kernel on sleep, and > > re-acquired one wakeup. This means that Giant does not provide mutual > > exclusion across a sleep -- if this is a property you are relying on, then > > Giant is not what you want. If you most sleep while holding a lock, I > > would recommend an sx lock. However, a preferred solution is not to sleep > > holding a lock. > > yes... sleepable as in "can be held while sleeping no matter how this is acomplished" > > I think the main problem (which is now fixed) was with this: > > copyin(addr, val1); > if (val1 == val2) > .... > > being non-atomic. On the other hand I tried to use other locks other then Giant and it > didnt work. I hope to investigate that later. Now I have this working and my focus is elsewhere. No, what you have done is wrong. The idea of doing copyin() and then compare is just plain not going to work. :) You will need to use casuptr() or the like similar to the umtx code. This is assuming that a futex can be manipulated from userland w/o entering the kernel. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608111249.44686.jhb>