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 Thu, 07 Aug 2003 22:43:01 GMT
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"


Mime
View raw message