On Mon, Jun 9, 2014 at 12:53 AM, Bart Van Assche <bvanass...@acm.org> wrote:
>
> I think g++ will have to be modified to allow Helgrind and DRD to
> recognize thread-safe statics on architectures that do not have relaxed
> memory consistency. From the gcc source file gcc/cp/decl.c I derived
> that on architectures without relaxed memory consistency that g++
> protects static initialization as follows:
>
>            static <type> guard;
>            if (!guard.first_byte) {
>              if (__cxa_guard_acquire (&guard)) {
>                bool flag = false;
>                try {
>                  // Do initialization.
>                  flag = true; __cxa_guard_release (&guard);
>                  // Register variable for destruction at end of program.
>                } catch {
>                  if (!flag) __cxa_guard_abort (&guard);
>                }
>            }

Interesting! So on x86 and similar, they implement thread-safe Meyers
singletons via the double-checked locking anti-pattern... Which is
actually safe thanks to Intel's not-exactly-relaxed memory model.

> If g++ would be modified such that the "if (!guard.first_byte)" test can
> be skipped at run-time then it would become possible for Helgrind and
> DRD to recognize static initialization

If I understand you correctly (?), you plan to ask the g++ maintainers
to tamper with their fast path to make life easier for Helgrind (?)

If so, I would suggest having a Plan B...

Would it make sense to re-think the happens-before/happens-after
annotation macros for C++11?

Or -- just thinking out loud here -- devise a way to encode this sort
of information in the debug section, and convince the GCC+Clang folks
to implement it (e.g. "-gannotate-memory-model" or somesuch)?

Here is my concern. C++11 provides a fairly elaborate threading and
memory model, with lots of built-in synchronization primitives, memory
barriers, various flavors of ordered loads and stores, etc. As more
and more of these get direct (open-coded) compiler support, and get
used for interesting lock-free algorithms and such, it is going to get
increasingly difficult for Helgrind to figure out what is going on.
Fixing this in general, if possible, would be better than playing
whack-a-mole.

Or am I way off base?

 - Pat

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to