I had a quick look into the apr sources. Their locks/unix/proc_mutex.c can map the proc_mutex functionality to various methods: 1) Posix sem implemenation (see mutex_posixsem_methods) 2) SysV sem implementation (see mutex_sysv_methods) 3) pthread implementation (see mutex_proc_pthread_methods) 4) fcntl implementation (see mutex_fcntl_methods) 5) flock implementation (see mutex_flock_methods)
I think only the pthread implemenation (3) is of interest here. The creation of the pthread_mutex happens at: locks/unix/proc_mutex.c:proc_mutex_proc_pthread_create that calls pthread_mutex_init with the following attributes: PTHREAD_PROCESS_SHARED, PTHREAD_MUTEX_ROBUST_NP, PTHREAD_PRIO_INHERIT The apr-phthread-mutex functionality relies on pthread_mutex_lock and pthread_mutex_trylock. The eglibc implemenation for such a mutex calls atomic_compare_and_exchange_val_acq (see also lll_lock/lll_trylock at ports/sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.h) which goes down to __arch_compare_and_exchange_val_32_acq. Using (e)glibc (>= 2.12.1-0ubuntu11) and GCC (>=4.5) this expands to __sync_val_compare_and_swap (ports/sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h) which should be safe even on a SMP system. Some infos regarding the atomic memory operations can be found at: https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#implementation%20details The next step would be to check whether the testcase fails using a decent GCC and eglibc (Ubuntu Natty for example). -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to apr in ubuntu. https://bugs.launchpad.net/bugs/604753 Title: [eglibc] process shared mutex's fail on armel v7 (thumb) -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
