Re: Critical Sections and Read operations.
Quote:
Originally Posted by
itsmeandnobodyelse
Wikipedia defines the race condition as
In case a (main) thread sets a shared boolean variable to true while multiple threads make a periodically check on that boolean therefore isn't a race condition. There is nothing unexpectedly and critically added when one of the threads reads the 'true' in the next period.
An atomic operation on a shared variable is only required if you want to be able to write from more than one thread and make sure that the second writer was reading the current value written by the frist writer. That normally only makes sense if you increment an integer or toggle a boolean cause if the writers don't (have to) care for the old contents (and that behavior isn't an error ) it actually isn't a race condition despite of two writers cause the result written is arbitrary anyhow depending on which thread was first or second.
In case of an incrementation or toggle you need synchronisation or an atomic setting cause otherwise you couldn't prevent from the case that two threads both do increment/toggle the old value hence one incrementation/toggle gets lost what is a race condition.
BTW, if the operation system offers an atomic incrementation (e. g. InterlockedIncrement of WINAPI) the atomic operation is guaranteed also for multi-processor and multi-core architectures. But of course on the latter systems an i++ in general isn't an atomic operation.
As I mentioned before - I'm not much interested in the special case of synchronization of boolean variables because I don't much use them in my multithreaded apps. While I might be classifying unwanted behavior as a 'race condition' for a non-synchronized boolean variable when it technically isn't a race condition, it still is unwanted behavior. At the end of the day, thread safety rules will still determine when a shared resource needs to be synchronized - it doesn't much matter what type the resource is (bool, int, string, etc.).
