apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <mma...@Doorways.org>
Subject RE: submission of new Windows rwlock code
Date Wed, 18 Jun 2003 22:14:09 GMT
> 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


Mime
View raw message