2009/8/27 Andrew Brampton <brampton+freebsd_at_gmail.com>: > Hi, > The following sequence of commands fails on line 4 with an assertion > that the lock is not currently held: > > 1: rw_wlock(&rw); > 2: if ( rw_try_wlock(&rw) ) > 3: rw_wunlock(&rw); > 4: rw_wunlock(&rw); > > This is because after line 3 is executed the rw lock is no longer > held. I tracked this bug down to _rw_try_wlock which correctly > increments rw_recurse, but does not set the RW_LOCK_RECURSED bit. > Without this bit the third line unlocks the lock and leaves it in a > unlocked state (when it should still be locked). Adding a line to set > this bit makes _rw_try_wlock match the code in _rw_wlock_hard. Sorry, but I really don't understand how that can be a bug. On STABLE_7, RW_LOCK_RECURSED is not used for checking if the lock is recursed or not. it just got set for improving debugging and eventually we decided to drop it for 8.0. However, for deciding if a lock is recursed or not in both STABLE_7 and HEAD we used just checking against the recursion count which is correctly handled by the function. What you describe can't be the problem. Attilio -- Peace can only be achieved by understanding - A. EinsteinReceived on Wed Aug 26 2009 - 20:57:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:54 UTC