This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: atomic accesses


Jakub Jelinek wrote:
On Tue, Mar 04, 2008 at 04:37:29PM +0000, Andrew Haley wrote:
Typically those would be found in asm statements.
I suspect it would be valuable to have standardized primitives for
atomic actions (semaphores, spinlocks, test-and-set primitives,
circular buffers, pick one).
We already have these in gcc, and they're even documented.

We don't have atomic read or atomic write builtins (ok, you could abuse __sync_fetch_and_add (&x, 0) for atomic read and a loop with __sync_compare_and_swap_val for atomic store, but that's a horrible overkill. Being able to assume that for non-bitfield accesses bigger than certain minimum size, smaller or equal to the word size and naturally aligned the compiler will read or write a value in one lump is certainly desirable and many programs assume it heavily (starting with glibc, kernel, libgomp, ...).

That seems reasonable, but I suspect that coming up with wordage to describe it sufficiently formally for all cases will be tricky.

AFAIK the only reason we don't break this rule is that doing so would
be grossly inefficient; there's nothing to stop any gcc back-end with
(say) seriously slow DImode writes from using two SImode writes instead.

The "certain minimum size" is typically either size of char, or (e.g. on old
alphas) size of int.  Typically the programs care about atomicity of
accesses to int, long and pointer sized vars, e.g. have only threads in
a critical section modify a variable, but be able to read that variable
outside of critical section and see only values that were written in the
critical section, not say half of an old value and half of a new value.

Andrew.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]