* Re: Concurrency items in C++11 status table
2012-04-13 12:48 ` Torvald Riegel
@ 2012-04-15 0:30 ` Lawrence Crowl
0 siblings, 0 replies; 3+ messages in thread
From: Lawrence Crowl @ 2012-04-15 0:30 UTC (permalink / raw)
To: Torvald Riegel; +Cc: Jonathan Wakely, gcc
On 4/13/12, Torvald Riegel <triegel@redhat.com> wrote:
> 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?
The intent of the paper was that there be no change to behavior.
It was motivated by both the apparent inherent confusion with
sequence points and by the concurrency work. If you find that
there is a change in semantics, please let the C++ committee know.
Data dependency ordering has both a weak implementation and a
strong implementation. The weak implementation promotes consume
operations to acquire and is suitable to strongly ordered machines.
The strong implementation actually tracks data dependences and is
suitable to weakly ordered machines. Which does gcc do? (It would
be worth noting that in the status page.)
>
> 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?
The standard doesn't know about dlclose, but the issue
was addressed in N2425 DRAFT C++ Dynamic Library Support
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2425.html
The essential notion is that a dynamic library author must make
sure that such variables and the threads that use them do not leak
outside the library so that they may be destructed on dlclose.
That notion is puts the burden on library writers, so the net result
of the above statement is that the implementation need do nothing
special about TLS with dlclose. As a word of caution, that paper
is only a draft. Dynamic libraries were one of the work items that
were pruned to meet the C++0x schedule.
> > > - 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.
I believe that no work is required for atomics in signal handlers.
The issue in the standard was to permit what would work anyway.
--
Lawrence Crowl
^ permalink raw reply [flat|nested] 3+ messages in thread