Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Jan 2016 18:12:29 +0100
From: Jens Gustedt <>
Subject: Re: atomic.h cleanup


Am Montag, den 11.01.2016, 17:35 +0100 schrieb Markus Wichmann:
> Really? OK, so it's either suboptimal code for everyone or
> compiler-specific better code. Why can't we have nice things?

nice things would be portable atomics, no?

> OTOH, maybe we simply shouldn't write synchronisation primitives
> ourselves and instead use the ones provided by GCC (and let other
> compilers suck on a salty sausage, if they don't support those
> primitives).

I think on the long run we should use C11 atomics and leave the dirty
work to the compiler writers. To my experience they do good work with
that now, the assembler they produce looks nice.

My stdatomic library is sitting there, ready to integrate into
musl. It solves the problem of backwards compatibility for all
compilers that that implement the __sync builtins. (gcc and clang with
very old version numbers.)

Last time I looked, all usages but one of atomic operations in musl
are clean. If an atomic operation is used for a data a some point,
atomic operations are used in all other places. So moving to
_Atomic(int) would be a option. (Basically this would be `volatile
int*` => `_Atomic(int)`, IIRC).


:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: ::

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.