apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr/locks/unix thread_mutex.c
Date Fri, 08 Aug 2003 01:41:42 GMT

On Thursday, August 7, 2003, at 04:44  PM, William A. Rowe, Jr. wrote:
> If this is a serious consideration - perhaps we have a problem with our
> implementation.

That's why the atomic stuff is optional. You can chose to make your
binaries incompatible if you so wish.

>   Note that the actual atomic logic (be it a macro around
> specific system calls, or some apache-internal implementation, or
> devolves to specialized assembly code) will be self-contained within
> the libapr.so/libapr.a, it isn't something that affects the actual 
> binary
> linked into libapr.

The problem isn't that we'll chose the wrong implementation at run
time, it's that the same binary that runs on one Solaris box won't 
run on another box, even if the other box has an equivalent or newer 
of Solaris.

> But I thought this was specific to our atomic/solaris/ implementation
> which has disappeared (due to licensing, iirc?)

I don't think it was solved, but I had a terrible memory for these 

> I wouldn't make this a consideration of the threads library, if we have
> problems with apr_atomic.h that make us unhappy, we should address
> that rather than worrying about 'should we use our own API?''

That is true. Also it is true that we have another couple of ways to
solve this:

1) Remove nested locks. Who's really using them anyway!?
2) Create a secondary internal mutex only when we need nested mutexes,
    and use that mutex to protect all accesses to the mutex->owner and
    mutex->owner_ref variables.


View raw message