Groups > comp.programming.threads > #1809

Re: forcing the compiler to reload from memory with c++0x

Path	csiph.com!eeepc.pasdenom.info!news.pasdenom.info!news.dougwise.org!gegeweb.org!eternal-september.org!feeder.eternal-september.org!feed.cnntp.org!news.cnntp.org!not-for-mail
From	Anthony Williams <anthony.ajw@gmail.com>
Newsgroups	comp.programming.threads
Subject	Re: forcing the compiler to reload from memory with c++0x
References	<4d3cee42$0$1209$426a74cc@news.free.fr> <1d21ad0a-db55-460e-aeb6-66f6d19369ea@i13g2000yqe.googlegroups.com> <4d3e2e3f$0$21517$426a34cc@news.free.fr> <4D40A4C7.16E6F9AE@web.de> <69d82db7-34be-4de7-86c4-2f39cc1e6df3@m13g2000yqb.googlegroups.com> <aebb655b-6821-4c19-a170-71633273366c@k32g2000vbn.googlegroups.com> <cd471590-cf8d-4830-b6fb-38aa2b7d4f30@h16g2000yqh.googlegroups.com> <87ipx9xxc0.fsf@justsoftwaresolutions.co.uk> <13cdd468-dee2-4dc6-9cf9-cc852db26fc5@d11g2000yql.googlegroups.com>
Date	Fri, 28 Jan 2011 09:31:50 +0000
Message-ID	<8762t9xtkp.fsf@justsoftwaresolutions.co.uk> (permalink)
User-Agent	Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock	sha1:h7r1TPWEMe/aKYZVIztKHcnLRlw=
MIME-Version	1.0
Content-Type	text/plain; charset=utf-8
Content-Transfer-Encoding	8bit
Lines	25
Organization	CNNTP
NNTP-Posting-Host	be5afc53.read.cnntp.org
X-Trace	DXC=kUo;F1c@kIVhm=^\mJ7;bRWoT\PAgXa?QC]U8mjb]54^31?8ZVJ3gMUGj6PdB418W^I_4@4jCSnG_`5]>C@^QJkV
X-Complaints-To	abuse@cnntp.org
Xref	csiph.com comp.programming.threads:1809

Show key headers only | View raw

Dmitriy Vyukov <dvyukov@gmail.com> writes:

> On Jan 28, 11:10 am, Anthony Williams <anthony....@gmail.com> wrote:
>
>> That is probably true in principle. Whereas before, compilers were
>> probably restricting themselves so that atomic accesses could be written
>> with plain variables (possible adorned with volatile), with C++0x they
>> know that writes to non-atomic variables do not have to be made visible
>> until an atomic operation with memory_order_release or stronger ordering
>> occurs, or some other synchronization event such as a mutex lock.
>
> A bit of formal hair-splitting.
> So does it really need to "flush" plain variables on mutex lock? I
> would expect that in presence of spuriously failing try_lock it does
> not actually need to do that.

Not on the lock (which is an acquire), but it will on the unlock (which
is a release).

Anthony
-- 
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++0x thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: forcing the compiler to reload from memory with c++0x frege <gottlobfrege@gmail.com> - 2011-01-27 21:34 -0800
  Re: forcing the compiler to reload from memory with c++0x frege <gottlobfrege@gmail.com> - 2011-01-28 19:43 -0800
    Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-30 22:07 +0000
  Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-28 08:10 +0000
    Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-28 00:45 -0800
      Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-28 09:31 +0000
  Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-28 00:09 -0800
    Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-01-29 15:49 +0100
      Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-01-31 15:53 -0500
    Re: forcing the compiler to reload from memory with c++0x frege <gottlobfrege@gmail.com> - 2011-01-28 19:28 -0800
      Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-29 01:41 -0800

csiph-web