Re: cxx-mem-model merge [6 of 9] - libstdc++-v3

[Andrew MacLeod <amacleod at redhat dot com>]

On 11/07/2011 11:24 AM, Joseph S. Myers wrote:
> On Mon, 7 Nov 2011, Andrew MacLeod wrote:
>
> > Actually, this target has no lock free support whatsoever?  ie, no
> > compare_and_swap instruction, nor an implementation of sync_lock_test_and_set
> > and sync_lock_release?
> >
> > I think the libstdc++ standard now requires the class atomic_flag to be lock
> > free in order to conform (n3242 29.7.2)
> >
> > So I guess this is the situation which all the atomic tests are not even
> > suppose to be run since they aren't supported.  My guess is that in the
> > previous releases the c++ header files probably provided a locked
> > implementation of test_and_set, and so the tests would run.
> For bare-metal targets there should maybe be an option to presume there is
> just one thread and map all atomic operations to dumb non-atomic versions,
> which is perfectly valid in such a case.  But that's a new feature; we
> didn't have it for __sync_* either.
Hmm. actually, there is a proposed option flag which I noticed never got 
implemented when I was looking back through stuff on the weekend:
http://gcc.gnu.org/wiki/Atomic/GCCMM/ExecutiveSummary

Exposure to the normal users can be provided through something along the 
lines of:

-fmemory-model=c++0x - Disable data races as per architectural requirements.
-fmemory-model=safe - Disable all data race introductions. (enforce all 
4 internal restrictions.)
-fmemory-model=single - Enable all data races introductions, as they are 
today. (relax all 4 internal restrictions.)

we could do that with -fmemory-model=single and it would be pretty 
natural...and easy.  The just fall back to a load for test and set and 
then atomic_flag would work fine.  Such targets would make that the 
default, and since the option isn't set to C++11, it wouldn't have to be 
conforming anyway.

Mostly I think it the option wasn't implemented because we never 
finished up with the load/store data race work.

We continue to count on  __sync_test_and_set and sync_lock_release for 
targets without a compare and swap operation to provide the atomic_flag 
implementation.

As for all the rest of the atomics, it defined right now that if the 
compiler cannot generate lock free instructions, it generates  a call to 
the external library.  I would suggest on such a limited  target that 
they build the library, and it would provide locked routines for all the 
rest of the external calls.  The library could also be configured for 
single thread operation which would then just provide the operation 
without locks if desired.

A buildable library is forthcoming in the next few months.

Andrew