apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <Softw...@Doorways.org>
Subject Re: recursive apr_thread_rwlock_wrlock?
Date Tue, 30 Mar 2004 22:09:52 GMT
On Tuesday 30 March 2004 03:16 am, Joe Orton wrote:
> On Mon, Mar 29, 2004 at 05:22:20PM -0500, Marc M. Adkins wrote:
> > On Monday 29 March 2004 01:16 am, Joe Orton wrote:
> > > On Sun, Mar 28, 2004 at 04:57:53PM -0500, Marc M. Adkins wrote:
> > > > Is it possible that apr_thread_rwlock_wrlock will allow recursive
> > > > behavior on Windows but not on Linux?  By this I mean that a specific
> > > > thread will request a write lock and then request the same write lock
> > > > again, intending to release it twice on the way out:
> > >
> > > Yes, that gives undefined behaviour in a POSIX implementation,
> > > apr_thread_rwlock.h on HEAD says:
> >
> > I am apparently not using anything close to the HEAD.
>
> No, not your fault, the comment isn't in 0.9.x and really should be.

> There are probably lots of things like this which are not documented at
> all in APR; if you want to get a better understanding of the assumptions
> you can make in threaded code on POSIXy systems you'd be well advised to
> go and read the relevant bits of the Single Unix spec: e.g.
> http://www.opengroup.org/onlinepubs/007904975/

Hey, that's a useful reference.

It's interesting that pthread_rwlock_wrlock() returns EDEADLK in the specific 
recursive call circumstance I describe.  Which would imply that a second lock 
from the same thread would wait on itself (as I observe it to do).  And yet 
the behavior is still not really defined, as you say.

Let me stray for a moment to my only contribution to this effort, dating back 
to June of last year.  I had discovered that the Win32 implementation of 
apr_thread_rwlock() starved writers.  I had a little test program that 
demonstrated that writers never wrote when there were too many overlapping 
readers.  On Linux it seemed to work OK, but on Windows it just wasn't good.

So after some correspondance on this very mailing list I took Brian Havard's 
OS/2 implementation of a non-starving rwlock and converted it very slightly 
for Win32 and it eventually made it into the code.  So now the APR rwlock is 
actually constructed of a mutex, an event, and a long integer on Win32 and it 
has a more predictable behavior, as well as being arguably more 'corrrect'.

Back to the current situation:  is it better to just say that the behavior is 
unpredictable (as in the recursive lock case) or to use available resources 
to construct something that has predictable behavior (as in the starvation 
case)?

I'm thinking that the starvation issue was 'wrong' in the sense that one 
couldn't build with it properly and therefore it needed to be fixed, whereas 
the recursive calls case isn't so much wrong as 'non-optimal,' it's perfectly 
usable as is, and I should have known better than to make such a ridiculous 
assumption in the first place.  Still, the solution in either case is 
essentially building a wrapper that combines multiple unpredictable beasties 
in such a way that the result becomes predicable.

Is there an articulated dividing line of some sort in these things?

mma


Mime
View raw message