apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: [PATCH] trial implementation of proc_pthread trylock
Date Sat, 24 Aug 2002 02:42:30 GMT
On Thu, Aug 22, 2002 at 03:59:24PM -0400, Chris Darroch wrote:
>    OK, pursuant to my previous email, here's a stab at an implementation
> of proc_mutex_proc_pthread_tryacquire().  Mostly I studied
> apr_thread_mutex_trylock() and proc_mutex_proc_pthread_acquire()
> to see what they were doing, plus read the man page a bit
> on what pthread_mutex_consistent_np() did.
>    With luck, the logic should be:
> - Check for non-zero return value.
> - If return value is EOWNERDEAD and we're trying to handle consistency
>   ourselves, call pthread_mutex_consistent_np() and set return
>   value to zero.
> - If return value is EBUSY, make it APR_EBUSY.
> - If return value is zero (APR_SUCCESS), set our lock flag.
> - Return.
>    The proc_mutex_proc_pthread_acquire() function seems to
> suck up the EOWNERDEAD return value, setting the curr_locked flag
> to 1 and returning APR_SUCCESS, so that's what I made the tryacquire
> case do also.
>    However, it seems to me that this behaviour, for both functions,
> might not be too helpful for callers, since any data they
> are protecting with our lock might be in an inconsistent state,
> but they'd have no way of determining that from our return value.
> Maybe we should invent an APR_EOWNERDEAD value and return that?

You are correct, but we can't invent an APR_EOWNERDEAD unless that
semantic is portable, which I don't believe it is. What happens to
a mutex right now when the owner dies, on platforms that don't have

I'm all for implementing trylock where possible, but I'm not comfortable
introducing non-posix/non-portable pthread calls.


View raw message