> At 07:05 PM 6/17/2003, Marc M. Adkins wrote: > >I've re-coded the Windows rwlock based on the OS/2 algorithm > implemented by > >Brian Havard. My test program doesn't show starvation with this > algorithm. > >I'm assuming that the code is stable and works correctly on > OS/2, and it's > >essentially the same code here, plus it passes all the tests I > know how to > >do so I'm submitting the code for review.
>From an offline discussion with Brian Havard: > >... in the unlock code... > >you check the value of the readers flag outside of the critical section. > >So in theory the readers flag could be changed between the check and the > >critical section in which it is decremented. > > > >In practice, this should never happen unless a read lock is unlocked twice. > >So arbitrarily bad code could result in questionable behavior. I think it's > >a non-issue. > > Ok, true, that could happen. The critical section could be brought up a > level to prevent that without any performance penalty (except for when > attempting to unlock a lock that's not locked which shouldn't be done > anyway). But in my port of Brian's code I don't use a critical section, I use the Windows equivalent of atomic variables. So while Brian could fix his implementation easily I would have to do some more rewrite, to bring it back into line with his version by creating a critical section in the unlock code. Frankly, I still think this is a non-issue in both cases. It can only happen if the APR user writes code that unlocks more than it locks, which indicates errors in the user code anyway. But it is potentially a hole in the algorithm, so I figured I had to at least write it up, in case the consensus was that a fix was in fact required. mma
