> In our application, we use bit fields a lot. For example:
>
>
>
> class data {
>
> unsigned int the_thread_1_data:1;
>
> unsigned int the_thread_2_data:3;
>
> …
>
> };
>
>
>
> When one thread is writing to the_thread_1_data, and another thread is
> reading or writing to the_thread_2_data, helgrind will flag racing condition.
> Is this a known issue in helgrind? Is there a way to get around this? I
> believe the operation is multithread safe.
>From the viewpoint of portability, bitfields are NEVER threadsafe!
This is particularly true on a RISC machine. The only way that one could
even imagine portable thread safety of a bitfield is for every update
to be performed via an atomic compare-and-swap instruction which covers
the enclosing addressable object ["unsigned int" above]. No compiler
is obligated to emit such code for Plain Old Data.
On a CISC machine such as x86, a one-bit field can be threadsafe
if the instructions are always "LOCK OR" or "LOCK AND". (or LOCK AND NOT,
which is not present on x86 until AVX2.) In particular, an assignment
from something which is not a literal constant cannot be threadsafe unless
the source is examined first for being 1 or 0, and then LOCK OR or LOCK AND
is used for the appropriate individual case.
A wider-than-one-bit field can be threadsafe similarly only if the values
are restricted to 0b0...0 or 0b1...1.
--
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
