Primitive synchronization primitives — safe?

Question

On constrained devices, I often find myself \"faking\" locks between 2 threads with 2 bools. Each is only read by one thread, and only written by the other. Here\'s what I m

Answer 1

Answering the questions.

Is this completely thread safe? I would answer no this is not thread safe and I would just not do this at all. Without knowing the details of our device and compiler, if this is C++, the compiler is free to reorder and optimize things away as it sees fit. e.g. you wrote:

is_paused = true;            
while(should_pause) sleep(50);            
is_paused = false;

but the compiler may choose to reorder this into something like this:

sleep(50);
is_paused = false;

this probably won't work even a single core device as others have said.

Rather than taking a lock, you may try to do better to just do less on the UI thread rather than yield in the middle of processing UI messages. If you think that you have spent too much time on the UI thread then find a way to cleanly exit and register an asynchronous call back.

If you call sleep on a UI thread (or try to acquire a lock or do anyting that may block) you open the door to hangs and glitchy UIs. A 50ms sleep is enough for a user to notice. And if you try to acquire a lock or do any other blocking operation (like I/O) you need to deal with the reality of waiting for an indeterminate amount of time to get the I/O which tends to translate from glitch to hang.