Date: Mon, 11 Jan 2016 20:03:56 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: atomic.h cleanup * Jens Gustedt <jens.gustedt@...ia.fr> [2016-01-11 18:12:29 +0100]: > Am Montag, den 11.01.2016, 17:35 +0100 schrieb Markus Wichmann: > > 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. > yes but old compilers had various bugs on various targets. > 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.) > i think simpler compilers like pcc, cparser, tcc dont implement that. if musl moves to compiler builtins then i'd like to have a possibility to compile atomic primitives as a separate tu > 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). > pthread_once_t and pthread_spinlock_t are publicly visibles type (without volatile and _Atomic) i dont think we can fix those without abi change.
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.