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, [EMAIL PROTECTED] 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"
