On Tue, Dec 3, 2013 at 12:13 AM, Daniel Lescohier <
[email protected]> wrote:
> The current time caching implementation in util_time.c and
> mod_log_config.c is not guaranteed to work with all compilers and cpu
> architectures. I have some proposed code I've written, that I want to get
> input from the mailing list on, before continuing on to compile and test it.
>
> The old implementation tries to do a wait-free algorithm, but incorrectly,
> because the algorithm relies on total memory ordering, and the
> implementation does not guarantee total memory ordering from the compiler
> or CPU.
>
> My proposal is to use the standard and portable apr_thread_mutex_trylock
> for enforcing the memory barriers. For APR's Linux x86_64 implementation,
> this basically turns into a lock: cmpxchgl instruction, and a lock: decl
> instruction for the unlock. Because only trylock is used, not lock, the
> futex is never spun and arbitrated on by the kernel, it's all done in
> userspace (if there's contention, each thread just calculates the value
> itself instead of reading from the cache). So the replacement is also a
> wait-free algorithm, using the standard and portable apr_thread_mutex
> calls. Also, the old algorithm does two memcpy operations when reading
> from the cache, while the new algorithm just does one. For
> APR_HAS_THREADS==0 or a non-threaded mpm in use, no locking is done
>
Is apr_thread_mutex_trylock really userspace/wait-free on all APR
supported patforms?
Currently, on the different platforms, it is implemented using :
- netware: NXTryLock()
- os2: DosRequestMutexSem(SEM_IMMEDIATE_RETURN)
- windows: TryEnterCriticalSection() / WaitForSingleObject() depending on
version
- POSIX(es): pthread_mutex_trylock()
Not to talk about BeOS where :
APR_DECLARE(apr_status_t) apr_thread_mutex_trylock(apr_thread_mutex_t
*mutex)
{
return APR_ENOTIMPL;
}
Wouldn't apr_atomic_cas32() be a better candidate?
Regards,
Yann.
