Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 23 Aug 2002 19:42:30 -0700
From: Aaron Bannert <aaron@clove.org>
To: dev@apr.apache.org
Subject: Re: [PATCH] trial implementation of proc_pthread trylock
Message-ID: <20020824024230.GA13980@clove.org>
Mail-Followup-To: Aaron Bannert <aaron@clove.org>, dev@apr.apache.org
References: <3D65429C.7080903@pearsoncmg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D65429C.7080903@pearsoncmg.com>
User-Agent: Mutt/1.4i

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
pthread_mutex_consistent_np()?

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

-aaron