This is the mail archive of the
mailing list for the GCC project.
Re: Thread-safety of a profiled binary (and GCOV runtime library)
- From: Nathan Sidwell <nathan at acm dot org>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Martin Liška <mliska at suse dot cz>, GCC Development <gcc at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Mon, 25 Jul 2016 08:23:39 -0400
- Subject: Re: Thread-safety of a profiled binary (and GCOV runtime library)
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <CAFiYyc0_wnuD2ogPVF+tXCqy6sa-vxWM8hb9fR1=acfRgAemail@example.com>
On 07/25/16 08:14, Richard Biener wrote:
There's pthread_detach () - do we wrap that appropriately? That said, another
way to make counters thread-safe is to allocate per-thread counters and update
those (for example by making the counters __TLS). The interesting part is then
to merge them with the main set of counters during thread exit (properly locked
or atomically of course). This would also solve the above mentioned issue but
have quite a cost on the memory side.
I'm not aware of any of the pthread fns being wrapped. (IIRC it's fork, execFOO
As you say, having TLS counters would increase memory, but I have no feel for
the relative increase it might be in codebases it'd affect. Compute-wise it's
probably no more expensive than using atomic adds, probably cheaper, if the
atomic ops are fn calls.