Hi Bernd,
I believe that all omp threads are created in detached state,
so pthread_join should be undefined on them, just tsan*thinks*
otherwise?
When I look further on the libgomp sources, I see there
are two completely different implementations of the
mutexes, barriers, etc.
One using posix
On 10/01/17 15:41, Thomas Koenig wrote:
> Am 01.10.2017 um 10:59 schrieb Bernd Edlinger:
>> maybe there is a way how you could explicitly join
>> all running threads?
>
> Yes, that seems to do the trick. Thanks!
>
Oh, that is really very surprising...
I believe that all omp threads are created
Am 01.10.2017 um 10:59 schrieb Bernd Edlinger:
maybe there is a way how you could explicitly join
all running threads?
Yes, that seems to do the trick. Thanks!
Here is a patch which appears to work. It does hit a snag with static
linking, though, because it calls __gthread_self (), and that ca
Hi,
I think this might be a false positive tsan warning.
Maybe tsan does not see why a desctructor function
can not execute before the last detached thread
terminates.
I created a small test case that receives a warning
which is similar to the one you tried to fix with your
patch:
cat test.c
#in
On Fri, Sep 29, 2017 at 9:53 PM, Thomas Koenig wrote:
> Am 29.09.2017 um 10:03 schrieb Janne Blomqvist:
>
>>
>> 1) I'm confused why fbuf_destroy is modified. The fbuf structure is
>> part of gfc_unit, and should be accessed with the same locking rules
>> as the rest of the gfc_unit components. Whe
Am 29.09.2017 um 10:03 schrieb Janne Blomqvist:
1) I'm confused why fbuf_destroy is modified. The fbuf structure is
part of gfc_unit, and should be accessed with the same locking rules
as the rest of the gfc_unit components. When closing the unit, I think
the same should apply here, no?
It is
On Fri, Sep 29, 2017 at 9:03 AM, Thomas Koenig wrote:
> I wrote:
>
>> This gets rid of the thread sanitizer issue; the thread sanitizer
>> output is clean. However, I would appreciate feedback about whether
>> this approach (and my code) is correct.
>>
>> Regression-tested.
>>
>
>
> Here is an up
I wrote:
This gets rid of the thread sanitizer issue; the thread sanitizer
output is clean. However, I would appreciate feedback about whether
this approach (and my code) is correct.
Regression-tested.
Here is an update: The previous version of the patch had a regression,
which is removed
Hello world,
the attached patch fixes the problem reported in PR 66756: When
opeing a file, the main lock for all units was acquired, the unit lock
was acquired, and then the main lock was released and re-aquired. To
the thread sanitizer, this is a lock-order inversion.
One option would have b
