mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1
Date: Sun, 23 Nov 2014 02:31:35 +0100	[thread overview]
Message-ID: <1416706295.16006.354.camel@eris.loria.fr> (raw)
In-Reply-To: <20141122233022.GE29621@brightrain.aerifal.cx>

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

Hi Rich,

Am Samstag, den 22.11.2014, 18:30 -0500 schrieb Rich Felker:
> atomic_flag is not viable for this because it does not have a
> wait/wake mechanism. You'd be spinning, which means in processes with
> different priorities involved, you could easily get deadlock if the
> lower-priority thread got suspended while holding the lock. You really
> do need mutexes.

I am probably still too much thinking in C11, only, which doesn't have
the notion of priorities.

Actually, I think a specially cooked synchronization tool would be
better. Something that combines an atomic pointer (to point to the
object) with a futex living on it for the waiting. This would probably
be a bit more challenging to implement, but here we really have an
interest to have the fast path really fast, just one CAS of the
pointer.

> > What has all of this to do with VLA? I am lost.
> 
> The operands of __typeof__ and sizeof get evaluated when they have VLA
> type. I think this is the problem.

ah, ok

No, this isn't a problem, I think. Arrays aren't allowed to be subject
of an _Atomic qualification (arrays are never qualified
themselves). For _Atomic type, the standard explicitly excludes
arrays. So arrays in general and VLA in particular should never be
passed as such into any of these generic functions, only pointers to
atomic objects can.

> > > I have changed it to be an atomic_bool in a struct as both GCC and Clang
> > > has it in a struct. Presumably to separate it from the generic _Atomic
> > > stuff.
> > 
> > Again, since we want to have ABI compatibility, it is not your choice
> > to make. You'd simply have to stick to the choice that gcc made. So
> > you have to copy the declaration of the struct, including all the
> > ifdef fuzz.
> 
> I'd have to look at it again, but IIRC only one case of the #ifdef
> mess was actually possible. The others were for hypothetical archs
> without real atomics which we can't support anyway.

We should have it as a struct, if the implementations have it like
that, I think:

 - It should have same alignment properties for ABI compatibility.
 - It should lead to the same typename when included in C++.

The ifdef is a single one to switch between _Bool or unsigned char or
so.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: 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: 198 bytes --]

  reply	other threads:[~2014-11-23  1:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-09 12:53 Joakim Sindholt
2014-11-09 17:11 ` Jens Gustedt
2014-11-22 20:52   ` Joakim Sindholt
2014-11-22 23:09     ` Jens Gustedt
2014-11-22 23:30       ` Rich Felker
2014-11-23  1:31         ` Jens Gustedt [this message]
2014-11-23  1:43           ` Rich Felker
2014-11-23  1:47             ` Joakim Sindholt
2014-11-23  2:42               ` Rich Felker
2014-11-23  9:43               ` Jens Gustedt
2014-11-23 15:21                 ` Rich Felker
2014-11-23 16:29                   ` Jens Gustedt
2014-11-23 16:38                     ` Rich Felker
2014-11-23 17:05                       ` Jens Gustedt
2014-11-23 17:29                         ` stephen Turner
2014-11-23 19:38                         ` Rich Felker
2014-11-23  8:49             ` Jens Gustedt
2014-11-23 15:06               ` Rich Felker
2014-11-23 16:18                 ` Jens Gustedt
2014-11-23 16:37                   ` Rich Felker
2014-11-23 18:01                     ` Jens Gustedt
2014-11-23 19:39                       ` Rich Felker
2014-11-23 23:30                         ` Jens Gustedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1416706295.16006.354.camel@eris.loria.fr \
    --to=jens.gustedt@inria.fr \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).