Open natale-p opened 1 year ago
Hi, could you please share the details of the system you are using for your application. Were you able to find a workaround using other available mutexes?
Hello @JhaShweta1, the OS is Debian 12 (when I tried GCC 12.1) and ArchLinux when I tried with GCC 13.2. I'm trying clang with macOs, and clang is 15.0.0.
Replacing tbb::queuing_rw_mutex
with tbb::queuing_mutex
(losing the r/w capability) solves the race. However, this is not something I would like to do. Thanks!
Replacing
tbb::queuing_rw_mutex
withtbb::queuing_mutex
(losing the r/w capability) solves the race. However, this is not something I would like to do. Thanks!
Hi @natale-p, Is there any specific architecture you are targeting? I believe tbb::queuing_rw_mutex
should work without issues on x86 and there is possible problems on weaker memory models such as ARM.
This particular issue in tbb::queuing_rw_mutex
is quite tricky (there are set of complex synchronizations) we still working on it.
Hello @pavelkumbrasev , this is happening on x86_64.
Any news on this? Do I need to raise the bug in GCC, as it's not happening with clang?
Hi @natale-p, the issue is still here. I was not able to fix it yet.
tbb::queuing_rw_mutex
should work fine on x86_64
(because of strict memory model) so you can safely use it on your platform.
I will try to return to this issue later.
Hello,
With a simple small test case I'm able to reproduce consistently a problem with tbb::queuing_rw_mutex, version v2021.9.0. TSAN reports a data race, that doesn't happen if I use
tbb::queuing_mutex
,std::shared_mutex
, orstd::mutex
. The logic behind the test case is that there are two threads, one continuously tries to retrieve the data stored in a shared data structure (the reader), while the other adds the data (the writer). It happens with GCC (from 12.0 to 13.2), but not with clang in macOs.The program is the following:
The output is the following:
TSAN is complaining about the access to the map while modifying the map itself when adding the element, as it wasn't protected by the rw_mutex. Do you think I can safely assume that the rw_mutex is race-free, and this is a false positive? Thanks in advance.