[cpp-threads] Causality on more than two processors, write atomicity

Herb Sutter hsutter at microsoft.com
Wed Sep 14 13:51:36 BST 2005


> You have to use some form of synchronization: whether it be built in
> locks, volatile variables, or things introduced by jsr-166.

Part of my question in that example was whether putting "volatile" on x
and y would be sufficient.

Herb


> -----Original Message-----
> From: Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk]
On
> Behalf Of Bill Pugh
> Sent: Thursday, September 08, 2005 8:02 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] Causality on more than two processors,write
> atomicity
> 
> 
> On Sep 5, 2005, at 4:42 PM, Herb Sutter wrote:
> >
> > Does that mean I can't always reliably maintain invariants, if I'm
> > using
> > unsynchronized updates (no locks) and the variables involved in the
> > invariant can be updated by more than one thread over the life of
the
> > program?
> 
> Correct.
> 
> If your program is not correctly synchronized, you get very weird
> behaviors, and you may
> have to understand the details of JSR-133 in order to understand the
> possible behaviors.
> The number of people who are capabile of designing correct algorithms
> with data races
> (conflicting non-volatile accesses not ordered by happens-before) is
> tiny (less than a
> dozen by my estimate). Doug and I spent hours going over a place in
> ConcurrentHashMap
> where Doug was deliberating undersynchronizing.
> 
> 
> You have to use some form of synchronization: whether it be built in
> locks, volatile
> variables, or things introduced by jsr-166. No one who writes
> undersynchronized
> code should be expecting any hand holding in helping them make their
> software reliable.
> 
>      Bill
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://decadentplace.org.uk/mailman/listinfo/cpp-
> threads_decadentplace.org.uk




More information about the cpp-threads mailing list