summaryrefslogtreecommitdiff
path: root/arch/x32/atomic.h
AgeCommit message (Collapse)AuthorLines
2015-08-16mitigate performance regression in libc-internal locks on x86_64Rich Felker-1/+1
commit 3c43c0761e1725fd5f89a9c028cbf43250abb913 fixed missing synchronization in the atomic store operation for i386 and x86_64, but opted to use mfence for the barrier on x86_64 where it's always available. however, in practice mfence is significantly slower than the barrier approach used on i386 (a nop-like lock orl operation). this commit changes x86_64 (and x32) to use the faster barrier.
2015-07-28fix missing synchronization in atomic store on i386 and x86_64Rich Felker-1/+1
despite being strongly ordered, the x86 memory model does not preclude reordering of loads across earlier stores. while a plain store suffices as a release barrier, we actually need a full barrier, since users of a_store subsequently load a waiter count to determine whether to issue a futex wait, and using a stale count will result in soft (fail-to-wake) deadlocks. these deadlocks were observed in malloc and possible with stdio locks and other libc-internal locking. on i386, an atomic operation on the caller's stack is used as the barrier rather than performing the store itself using xchg; this avoids the need to read the cache line on which the store is being performed. mfence is used on x86_64 where it's always available, and could be used on i386 with the appropriate cpu model checks if it's shown to perform better.
2015-05-20fix inconsistency in a_and and a_or argument types on x86[_64]Rich Felker-4/+4
conceptually, and on other archs, these functions take a pointer to int, but in the i386, x86_64, and x32 versions of atomic.h, they took a pointer to void instead.
2014-10-10add explicit barrier operation to internal atomic.h APIRich Felker-0/+5
2014-07-27clean up unused and inconsistent atomics in arch dirsRich Felker-25/+0
the a_cas_l, a_swap_l, a_swap_p, and a_store_l operations were probably used a long time ago when only i386 and x86_64 were supported. as other archs were added, support for them was inconsistent, and they are obviously not in use at present. having them around potentially confuses readers working on new ports, and the type-punning hacks and inconsistent use of types in their definitions is not a style I wish to perpetuate in the source tree, so removing them seems appropriate.
2014-02-23import vanilla x86_64 code as x32rofl0r-0/+125