On 08/05/16 09:43, Martin Liška wrote:
On 08/05/2016 03:14 PM, Nathan Sidwell wrote:
On 08/05/16 08:48, Martin Liška wrote:
Ok, after all the experimenting and inventing "almost" thread-safe code, I
incline to not to include __gcov_one_value_profiler_body_atomic
counter. The final solution is
On 08/05/2016 03:14 PM, Nathan Sidwell wrote:
> On 08/05/16 08:48, Martin Liška wrote:
>
>> Ok, after all the experimenting and inventing "almost" thread-safe code, I
>> incline to not to include __gcov_one_value_profiler_body_atomic
>> counter. The final solution is cumbersome and probably does
On 08/05/16 08:48, Martin Liška wrote:
Ok, after all the experimenting and inventing "almost" thread-safe code, I
incline to not to include __gcov_one_value_profiler_body_atomic
counter. The final solution is cumbersome and probably does not worth doing.
Moreover, even having a thread-safe imp
On 08/05/2016 02:38 PM, Nathan Sidwell wrote:
> On 08/05/16 04:55, Martin Liška wrote:
>
>> Thank you for very intensive brainstorming ;) Well I still believe that
>> following code
>> is not thread safe, let's image following situation:
>>
>
> yeah, you're right.
>
>>> we could do better by us
On 08/05/16 04:55, Martin Liška wrote:
Thank you for very intensive brainstorming ;) Well I still believe that
following code
is not thread safe, let's image following situation:
yeah, you're right.
we could do better by using compare_exchange storing value, and detect the race
I mentione
On 08/04/2016 07:03 PM, Nathan Sidwell wrote:
> On 08/04/16 12:43, Nathan Sidwell wrote:
>
>> How about:
>> gcov_t expected;
>> atomic_load (&counter[0], val, ...);
>> gcov_t delta = val == value ? 1 : -1;
>> atomic_add (&counter[1], delta); <-- or atomic_add_fetch
>> if (delta < 0) {
>> /* c
On 08/04/16 12:43, Nathan Sidwell wrote:
How about:
gcov_t expected;
atomic_load (&counter[0], val, ...);
gcov_t delta = val == value ? 1 : -1;
atomic_add (&counter[1], delta); <-- or atomic_add_fetch
if (delta < 0) {
/* can we set counter[0]? */
atomic_load (&counter[1], &expected, ...);
On 08/04/16 11:34, Martin Liška wrote:
On 08/04/2016 04:48 PM, Nathan Sidwell wrote:
diff --git a/libgcc/libgcov-profiler.c b/libgcc/libgcov-profiler.c
+static inline void
+__gcov_one_value_profiler_body_atomic (gcov_type *counters, gcov_type value)
+{
...
The body looks to have data races. So
On 08/04/2016 04:48 PM, Nathan Sidwell wrote:
> diff --git a/libgcc/libgcov-profiler.c b/libgcc/libgcov-profiler.c
> +static inline void
> +__gcov_one_value_profiler_body_atomic (gcov_type *counters, gcov_type value)
> +{
> ...
>
> The body looks to have data races. Some kind of cmp_store needed
On 08/01/16 09:29, Martin Liška wrote:
I also added a small hunk that describes problematic of app having not-joined
(or detached) threads,
can you please take a look at documentation change, maybe it would need some
transformation?
sorry for the tady response,thanks for the ping.
In genera
On 08/01/2016 02:22 PM, Nathan Sidwell wrote:
> As I just wrote, this patch needs work. the general points are:
Thank for the comments.
> 1) exposing integers 0-3 to the user as switch values. Don't do that, give
> them names. In this case a comma separated list of orthogonal names seems
>
As I just wrote, this patch needs work. the general points are:
1) exposing integers 0-3 to the user as switch values. Don't do that, give them
names. In this case a comma separated list of orthogonal names seems
appropriate. But see below.
2) Poor documentation. How might the user might
12 matches
Mail list logo
