Re: Protect bool on concurrent access
On 1 Jun., 10:57, Johan Torp <johan.t...@gmail.com> wrote:
I have a bool which will transition from false to true once. One
thread sets the bool to true (once), the other reads it every now and
then. I know C++03 and 0x has undefined behaviour, but in practice...
Is it necessary to protect such bools? Are there any known hardware/
platform/compilers which might cause problems?
Yes, this will cause problems on multi-processor/multi-core machines.
What problems? Will the program crash on any known compiler/
architecture? If not, what could possibly be the problem?
You should mark the variable as volatile and use a memory fence to
make the value visible to the other threads. Under windows this can be
done using the InterlockedExchange() function.
I don't care about memory consistency. One thread will write the
variable _once_, another will do something _once_ when it detects it
is not false. So even if the variable flickers back and forth between
true and false for a while it doesn't matter. Even undefined
intermittent values doesn't matter since they will all evaluate to
true or false. All that matters is that:
A. The write is seen eventually
B. The program doesn't crash
Sorry for taking so long time to respond, my google groups
notifications don't seem to be working.
This depends on your hardware architecture, of course. Francis
Glassborow explained that booleans are allowed to hold trap-
representations. While this is true, no mainstream processer is going
to trap.
The question is why your thread would have to wait for the flag: most
certainly, it must be waiting for something else as well? As an
example:
int global_1;
bool global_1_initialised = false;
thread 1:
global_1 = 42;
global_1_initialised = true;
thread 2:
while (!global_1_initialised) do_something_else();
std::cout << global_1;
In this example thread 2 is not guaranteed to write 42, the reason
being that the cpu decides to flush the cache-line containing the
boolean before it flushes the cache-line containing the integer. For
this to work correctly, you need special code.
Another possibility is that the processor for some reason decides not
to flush the cache-line containing the bool. In that case the second
thread will never get to the cout statement.
I believe both possibilities are realistic with common processors
today.
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]