Re: Concurrency items in C++11 status table

[Torvald Riegel <triegel@redhat.com>]

On Fri, 2012-04-13 at 10:46 +0100, Jonathan Wakely wrote:
> The table at http://gcc.gnu.org/projects/cxx0x.html indicates most of
> the concurrency work is not done, but I think the status is better
> than it shows.
> 
> If I'm not mistaken strong CAS and bidirectional fences are done.
> 
> Does anything need to be done for atomics in signal handlers?
> 
> at_quick_exit() is available in glibc, is anything needed from GCC?
> 
> Are any compiler changes needed for sequence points, or is it just a
> re-wording of existing rules to make sense in a multi-threaded world?

We recently spoke about this:

On Thu, 2012-04-12 at 10:15 -0400, Jason Merrill wrote:
On 04/11/2012 05:46 PM, Torvald Riegel wrote:
> > For the mem model and such yes, but for the following too?:
> > - Dynamic initialization and destruction with concurrency
> 
> No.  We hold a lock during static local variable initialization,
> which 
> can lead to deadlock.  We don't support concurrent initialization or 
> destruction of objects with unordered initialization.
> 
> > - Thread-local storage
> 
> We have our own version of TLS, but haven't added the standard
> version.

Jakub pointed out that ctors/dtors for TLS objects could be tricky (when
combining with dlopen/dlclose).  He further said:
So, if the standard allows ctors/dtors for TLS vars, I wonder if it can
be supported at all and how.  What do others do?  Do they just ignore
dlclose? Or should we just disable dlclosing of libraries that have
constructed such vars, or defer them until there will be just a single
thread?

> 
> > - Abandoning a process and at_quick_exit
> 
> No.

But Jakub points out glibc having at_quick_exit.

> 
> > - Allow atomics use in signal handlers
>  > - Sequence points
> 
> I would guess that these don't require any changes, but haven't
> verified 
> this.