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 Newsgroups: comp.std.c,comp.lang.c Subject: Re: The threading specs in the standard: a new catastrophe Date: Thu, 21 Jul 2011 11:56:41 +0200 Organization: A noiseless patient Spider Lines: 61 Message-ID: <4E27F7D9.7DE4607D@web.de> References: <97m59uF1nsU1@mid.individual.net> <97mluqFbcvU6@mid.individual.net> <4E16D89D.20302@loria.fr> <4E199F58.70606@loria.fr> <4E1B622A.5090506@loria.fr> <4E1BE0BB.6010100@loria.fr> <4E21471A.8090703@loria.fr> <87wrfgban1.fsf@catnip.gol.com> <4E248E98.5271CFD2@web.de> <4E25260B.4050507@loria.fr> Reply-To: terekhov@web.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="19004"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+6bQe0GepTZ+1Ze5cm4/ngiz1cdJVY5xc=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:FdsogrtISG6E/ArMXJDS75wqbjs= Xref: x330-a1.tempe.blueboxinc.net comp.std.c:733 comp.lang.c:8538 Jens Gustedt wrote: > > Hello, > > Am 07/18/2011 09:50 PM, schrieb Alexander Terekhov: > > Miles Bader wrote: > >> The work is already being done, for c++0x atomic support, no? > > > > AFAIK, to the extent of > > > > http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html > > This is already a start, but not the same as implementing the _Atomic > keyword in C1x, I guess. This goes more in direction of implementing > the atomic macro/functions by the help of builtins. > > You'd have to synthesize the correct arithmetic operations for all > primitive types for which the compiler is supposed to support _Atomic. I think that _Atomic keyword sucks miserably. I also don't like C++0x atomics. I think that atomic loads and stores ought to support the following 'modes': Whether load/store is competing (default) or not. Competing load means that there might be concurrent store (to the same object). Competing store means that there might be concurrent load or store. Non-competing load/store can be performed non-atomically. Whether competing load/store needs remote write atomicity (default is no remote write atomicity). A remote-write-atomicity-yes load triggers undefined behaivior in the case of concurrent remote- write-atomicity-no store. Whether load/store has specified reordering constraint (default is no constraint specified) in terms of the following reordering modes: Whether preceding loads (in program order) can be reordered across it (can by default). Whether preceding stores (in program order) can be reordered across it (can by default). Whether subsequent loads (in program order) can be reordered across it (can by default). For load, the set of constrained subsequent loads can be limited to only dependant loads (aka 'consume' mode). Whether subsequent stores (in program order) can be reordered across it (can by default). For load, there is an implicit reordering constraint regarding dependent stores (no need to specify it). A fence/barrier operation can be used to specify reordering constraint using basically the same modes. regards, alexander.