PERFORCE change 103633 for review

[John Baldwin]

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 at 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