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
