stdatomic implementation

stdatomic implementation

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Hello everybody,
as Rich suggested at some point, I have now wrapped up my code for the
library part of atomics in a standalone library. I should work with
most versions of gcc or clang that are around, with evidently a
different degree of C11 support according to the particular version.

Its integration into musl should be straight forward and remains my
primary choice for having it distributed. You can find it at

stdatomic.gforge.inria.fr

Under the hood it uses a new lock algorithm based on futex waits for
the slow path, that has proven to be more efficient than anything else
that I looked at: musl's internal lock, mtx_t or pthread_mutex_t, or
spinlocks. You can find a discussion of that at

https://hal.inria.fr/hal-01236734

Before I go (more) public with this, I would very much like to hear
what you think.

Thanks

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: stdatomic implementation

[Szabolcs Nagy]

* Jens Gustedt <jens.gustedt@inria.fr> [2015-12-13 11:01:22 +0100]:
> Its integration into musl should be straight forward and remains my
> primary choice for having it distributed. You can find it at
> 
> stdatomic.gforge.inria.fr
> 

nice

i recently run into a problem that you may be interested in:
the gcc atomic builtins do not handle atomic pointer types as
expected.

T *p;
__atomic_fetch_add(&p,1);

adds 1 to (char*)p instead of sizeof(T).

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64843

> Under the hood it uses a new lock algorithm based on futex waits for
> the slow path, that has proven to be more efficient than anything else
> that I looked at: musl's internal lock, mtx_t or pthread_mutex_t, or
> spinlocks. You can find a discussion of that at
> 
> https://hal.inria.fr/hal-01236734
> 
> Before I go (more) public with this, I would very much like to hear
> what you think.

i havent read the paper yet but it is worth noting that
glibc implements weaker pthread semantics than musl, so
on glibc pthread_mutex_lock/unlock is acquire/release.
(which makes pthread_mutex_trylock non-conforming, but
it's closer to the c11 semantics, same for spinlocks).

so it would be interesting to benchmark against glibc
primitives too.

Re: stdatomic implementation

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]

Hello,

Am Sonntag, den 13.12.2015, 15:59 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@inria.fr> [2015-12-13 11:01:22 +0100]:
> > Its integration into musl should be straight forward and remains my
> > primary choice for having it distributed. You can find it at
> > 
> > stdatomic.gforge.inria.fr
> > 
> 
> nice
> 
> i recently run into a problem that you may be interested in:
> the gcc atomic builtins do not handle atomic pointer types as
> expected.
> 
> T *p;
> __atomic_fetch_add(&p,1);
> 
> adds 1 to (char*)p instead of sizeof(T).
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64843

thanks, I wasn't aware of that one.

FYI in a recent DR about atomics, among other things, I pointed on the
missing specification of atomic_fetch_add for pointer types. I think I
can safely say that the consensus among the committee for that
specific problem was to say that this was just an omission in
C11. Unfortunately, that DR opened a whole can of worms about atomics.
I was asked to cut it down in smaller pieces that will easier to
tackle with the DR process.

> > Under the hood it uses a new lock algorithm based on futex waits for
> > the slow path, that has proven to be more efficient than anything else
> > that I looked at: musl's internal lock, mtx_t or pthread_mutex_t, or
> > spinlocks. You can find a discussion of that at
> > 
> > https://hal.inria.fr/hal-01236734
> > 
> > Before I go (more) public with this, I would very much like to hear
> > what you think.
> 
> i havent read the paper yet but it is worth noting that
> glibc implements weaker pthread semantics than musl, so
> on glibc pthread_mutex_lock/unlock is acquire/release.
> (which makes pthread_mutex_trylock non-conforming, but
> it's closer to the c11 semantics, same for spinlocks).

Hm, interesting. From our lengthy discussion, here, about mutexes and
conditions last year I had the vague impression that for musl also
this was more-or-less acquire/release, at least to completely seq_cst,
either.

> so it would be interesting to benchmark against glibc
> primitives too.

Yes, probably, also it would be interesting to have it on more
architectures and for more test cases.

Thanks

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: stdatomic implementation

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Am Sonntag, den 13.12.2015, 15:59 +0100 schrieb Szabolcs Nagy:
> i recently run into a problem that you may be interested in:
> the gcc atomic builtins do not handle atomic pointer types as
> expected.
> 
> T *p;
> __atomic_fetch_add(&p,1);
> 
> adds 1 to (char*)p instead of sizeof(T).
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64843

thanks again for pointing me at this

Since here we can assume that we flat addressing and that we also have
C11's _Generic, a workaround is simple. I have now implemented this,
and as long as one is using my header file and not gcc's it seems to
work.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]