Re: cvs commit: apr/locks/unix thread_mutex.c

[Aaron Bannert <aa...@clove.org>]

Won't this introduce a binary dependency on the implementation
of the atomics? What I mean is before, code that used the atomics
was restricted in some cases (solaris) on the same type of underlying
hardware, and could no longer rely on the version of the OS to
determine binary compatibility. Now we're extending that requirement
to any code that uses thread mutexes. Can we come up with another
solution that doesn't introduce the dependency?

-aaron



On Thursday, August 7, 2003, at 03:16  PM, wrowe@apache.org wrote:

> wrowe       2003/08/07 15:16:24
>
>   Modified:    include/arch/unix apr_arch_thread_mutex.h
>                locks/unix thread_mutex.c
>   Log:
>     Revamp apr_thread_mutex to be as thread safe, and occasionally
>     as reentrant as possible.  Switched to atomics to preserve the
>     incr/decr integrity.
>
>     Although we previously reset the thread_id to zero, it's been
>     pointed out on list that this is less than desireable.  However,
>     negative one isn't necessarily a good choice because several
>     platforms have unsigned thread_t's.
>
>   Revision  Changes    Path
>   1.2       +3 -2      apr/include/arch/unix/apr_arch_thread_mutex.h
>
>   Index: apr_arch_thread_mutex.h
>   ===================================================================
>   RCS file: /home/cvs/apr/include/arch/unix/apr_arch_thread_mutex.h,v
>   retrieving revision 1.1
>   retrieving revision 1.2
>   diff -u -r1.1 -r1.2
>   --- apr_arch_thread_mutex.h	6 Jan 2003 23:44:26 -0000	1.1
>   +++ apr_arch_thread_mutex.h	7 Aug 2003 22:16:24 -0000	1.2
>   @@ -60,6 +60,7 @@
>    #include "apr_general.h"
>    #include "apr_thread_mutex.h"
>    #include "apr_portable.h"
>   +#include "apr_atomic.h"

Re: cvs commit: apr/locks/unix thread_mutex.c

[Aaron Bannert <aa...@clove.org>]

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 
necessarily
run on another box, even if the other box has an equivalent or newer 
version
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 
things.

> 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.

-aaron

Re: cvs commit: apr/locks/unix thread_mutex.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 05:43 PM 8/7/2003, Aaron Bannert wrote:
>Won't this introduce a binary dependency on the implementation
>of the atomics? What I mean is before, code that used the atomics
>was restricted in some cases (solaris) on the same type of underlying
>hardware, and could no longer rely on the version of the OS to
>determine binary compatibility. Now we're extending that requirement
>to any code that uses thread mutexes. Can we come up with another
>solution that doesn't introduce the dependency?

If this is a serious consideration - perhaps we have a problem with our
implementation.  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.

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

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?''

Bill