Re: Optimization/clarity coding : what is gcc able to do for me ?

[Joe Buck <Joe dot Buck at synopsys dot COM>]

Robert Dewar wrote:
> > There is no rule against the use of shared variables, yes, of course you
> > have to be careful, but there are many algorithms that use variables
> > that are read by one task and written by another, that work fine. Surely
> > you are not claiming that these algorithms are never allowed in C.

On Sat, Jan 15, 2005 at 04:12:35PM +0100, jlh wrote:
> Of course not.  It's up to the user to know what he's doing and there's
> the volatile keyword to avoid incorrect optimizations.
 
> What I said was only meant for the mentioned situation of a std::vector,
> which needs to be in a coherent state in order to be read correctly.
> When a thread manipulates a vector, it might be in an incoherent state
> for a short time, during which it would be dangerous for another thread
> to read this same vector.

The answer is that there is no protection, and this is true not only for
an std::vector variable, but even for a "long long" variable on a 32-bit
platform.  (In other words, what you are asking for is not even
implemented for "long long").  Two competing threads accessing such a
variable will make a big mess, in the absence of added protection.

It's up to you as a programmer to implement locking if you want to access
any variable longer than a "sig_atomic_t" (which is a typedef that defines
an integral type for which accesses are guaranteed to be atomic on your
system; it is often "int", but might not be).  Pointer accesses are atomic
on every machine that I know of, though I am not certain that the language
standard guarantees this.

The only type of thread safety provided by libstdc++ is that sharing that
happens "behind your back" (like reference counting and allocation pools)
is done in a thread-safe way.