Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Alexander Terekhov <terekhov@web.de>
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: The threading specs in the standard: a new catastrophe
Date: Fri, 22 Jul 2011 21:36:52 +0200
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <4E29D154.ED3B37F9@web.de>
References: <iv422a$33k$1@speranza.aioe.org> <97m59uF1nsU1@mid.individual.net> <97mluqFbcvU6@mid.individual.net> <4E16D89D.20302@loria.fr> <ivaj54$rlt$1@dont-email.me> <4E199F58.70606@loria.fr> <ivfhi1$olt$1@dont-email.me> <4E1B622A.5090506@loria.fr> <ivfrj7$sma$1@dont-email.me> <4E1BE0BB.6010100@loria.fr> <ivqhl6$h50$1@dont-email.me> <4E21471A.8090703@loria.fr> <j0cfmc$e8b$1@dont-email.me>
Reply-To: terekhov@web.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="10472"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX185nPdRvAM8divSsfDL1M9jrPBp29qFxM4="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:BIJtj/LTcF/JYZLXNQ3Y2vGCkqE=
Xref: x330-a1.tempe.blueboxinc.net comp.std.c:736 comp.lang.c:8601


Marcin Grzegorczyk wrote:
> 
> Jens Gustedt wrote:
> > Am 07/16/2011 01:14 AM, schrieb Marcin Grzegorczyk:
> >> Jens Gustedt wrote:
> >>> I don't think that just one proprietary implementation will contribute
> >>> to a wide spread acceptance. You'd need at least one major compiler
> >>> implementor adopt it on each side, windows and unix. On the unix side
> >>> this'd better be gcc or clang, so something with an open license of
> >>> some sort.
> >>
> >> Glibc, rather than GCC.  If the final standard includes the<threads.h>
> >> as the current draft describes it, I expect it to be implemented pretty
> >> soon in glibc (after all, it's just a thin wrapper over pthreads).
> >
> > So you distiguish the threads support from the atomic support?
> 
> The WG14 certainly has agreed they are different things; that's why
> there is __STDC_NO_ATOMICS__ in the first place (earlier drafts had just
> __STDC_NO_THREADS__).
> 
> For the rationale, see the WG14 documents N1553 (comment CA 4) and N1558

N1555:

"There is a current macro that says if 
you have stdc_no_threads, if that is 
defined, then you don’t need to provide 
the stdcatomic.h header. These are 
different things. Specifically, threads 
belong to the OS and atomics belongs 
to the hardware. In embedded system, 
you want hardware support and not 
have OS come along for the ride. "

> (pp.14-15).  In summary, atomics can be useful even without threads

"Threads and atomics are different 
things. Specifically, threads belong
to the OS and atomics belong to the
hardware. The OS should provide common
locking implementations so that 
different compilers don't do 
incompatible things. In embedded 
system, you want hardware support and
not have OS come along for the ride.
We should separate __STDC_NO_THREADS
from stdatomic.h. We suggest 
__STDCATOMIC__ be defined if the
system provides atomics and the
atomic header.

We would have atomics in all cases,
with or without threads."

<chuckles>

The quoted N1555 et al text above is 
utter nonsense.

Without threads, we already have 
sig_atomic_t.

regards,
alexander.