It looks like apr_atomic is not in good-enough shape to be used for
lock-free algorithms. It's probably good enough for the use-cases that the
event mpm uses it for, because the event mpm is not using it for protecting
memory besides the counters it's atomically changing. However, the time
Some timing tests:
gcc -I/usr/include/apr-1 -lrt -lapr-1 -lpthread test.c
./a.out
apr_time_exp_lt: 108 nanosecs per call
localtime_r: 85 nanosecs per call
apr_time_exp_gmt: 59 nanosecs per call
gmtime_r: 35 nanosecs per call
pthread_mutex_trylock/unlock/read cache: 19 nanosecs per call
On Sunday 06 January 2013, Daniel Lescohier wrote:
I'm not sure we should include memory barriers inside the
apr_atomic_read32 and apr_atomic_set32 functions, because you
don't necessarily need a full memory barrier on each read or set.
Instead, perhaps we should add three functions to APR:
On Saturday 05 January 2013, Daniel Lescohier wrote:
apr_atomic_read32 is not implemented with a memory barrier. The
implementation of apr_atomic_read32 in the APR code base is just a
read from a pointer marked volatile. E.g., here is the
atomic/unix/builtins.c implementation:
- Original Message -
On Saturday 05 January 2013, Daniel Lescohier wrote:
apr_atomic_read32 is not implemented with a memory barrier. The
implementation of apr_atomic_read32 in the APR code base is just a
read from a pointer marked volatile. E.g., here is the
Sigh. I was too much focused on x86. There the compiler barrier
caused
by the function call is enough. But you are right, on other
architectures these functions may also require cpu memory barriers.
on x86 … is enough - would it harm x86 to add CPU barriers, or
do we want to have #
I'd have to go back and review the Intel documentation to be sure, but for
this particular algorithm, an explicit memory barrier may be required on
Intel architecture, also. If I remember correctly, without a memory
barrier, Intel arch only guarantees total memory ordering within one cache
line.
I was wrong about the Intel architecture: it has a pretty strong
memory-ordering guarantee. But other architectures, like PowerPC and ARM,
have a weak memory-ordering guarantee. Here is a good summary:
https://en.wikipedia.org/wiki/Memory_ordering. The doc in footnote 3 is a
good document to
I entered a bug on the thread-safety of the time conversion caches in
server/util_time.c and modules/loggers/mod_log_config.c.
In brief, they're not thread-safe because:
1. The algorithm depends on total memory ordering, and both the volatile
qualifier and memory barriers are not used.
On Friday 04 January 2013, Daniel Lescohier wrote:
I entered a bug on the thread-safety of the time conversion caches
in server/util_time.c and modules/loggers/mod_log_config.c.
In brief, they're not thread-safe because:
1. The algorithm depends on total memory ordering, and both the
apr_atomic_read32 is not implemented with a memory barrier. The
implementation of apr_atomic_read32 in the APR code base is just a read
from a pointer marked volatile. E.g., here is the atomic/unix/builtins.c
implementation:
APR_DECLARE(apr_uint32_t) apr_atomic_read32(volatile apr_uint32_t
11 matches
Mail list logo
