From dev-return-9978-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Jun 18 21:33:40 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 529 invoked by uid 500); 18 Jun 2003 21:33:40 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 518 invoked from network); 18 Jun 2003 21:33:39 -0000 From: "Marc M. Adkins" To: "APR developers" Subject: RE: submission of new Windows rwlock code Date: Wed, 18 Jun 2003 15:14:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <5.2.0.9.2.20030617192306.024af528@pop3.rowe-clan.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > 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