Excellent video, topic explained very well. Thank you! The only thing I did not understand was when you mentioned that there was still undefined behavior; if one thread finished its work before the second thread started. Why would this lead to undefined behavior? Would this not be equivalent to doing the work in a single thread, i.e. no race conditions?
The issue is due to a race condition. Atomic operations are one such tool that is lighter than mutexes and their associated locks, such as lock_guard, unique_lock, and condition variables, which are used to prevent race conditions and ensure mutual exclusion. Without atomic operations, it might lead to race conditions. The cause of a race condition is when two threads accessing the same resource, such as a global variable, simultaneously read a value from the RAM, perform an incremental operation, and then store it back in the RAM, which leads to an invalid value.
"""if one thread finished its work before the second thread started. Why would this lead to undefined behavior? Would this not be equivalent to doing the work in a single thread, i.e. no race conditions?"""" it is either he might have said it wrong or you heard it wrong. if first thread starts and finished without second thread even gets a chance to execute, then obviously there is no way undefined behavior will occur.
Very good presentation mate. I would love your take on more approaches to deal with this case if any. For instance when setting the atomic value, is it slower runtime?
While it would run slightly slower, you can't focus on speed in a case like this. It's the difference between yielding an accurate result or crashing. The example here may be simple enough that it would likely never crash, but there are numerous cases where you can really destroy your data by not handling threads correctly. You should practice what he shows in the video and watch the one he did on mutices.
Excellent and clear explanation! thanks!
Good content, as always.
Glad to hear it :^)
Excellent video, topic explained very well. Thank you!
The only thing I did not understand was when you mentioned that there was still undefined behavior; if one thread finished its work before the second thread started.
Why would this lead to undefined behavior? Would this not be equivalent to doing the work in a single thread, i.e. no race conditions?
The issue is due to a race condition. Atomic operations are one such tool that is lighter than mutexes and their associated locks, such as lock_guard, unique_lock, and condition variables, which are used to prevent race conditions and ensure mutual exclusion. Without atomic operations, it might lead to race conditions. The cause of a race condition is when two threads accessing the same resource, such as a global variable, simultaneously read a value from the RAM, perform an incremental operation, and then store it back in the RAM, which leads to an invalid value.
"""if one thread finished its work before the second thread started.
Why would this lead to undefined behavior? Would this not be equivalent to doing the work in a single thread, i.e. no race conditions?"""" it is either he might have said it wrong or you heard it wrong. if first thread starts and finished without second thread even gets a chance to execute, then obviously there is no way undefined behavior will occur.
nice and simple example
Thanks! Glad you thought so! :^)
thanks Nick!!
Very good presentation mate.
I would love your take on more approaches to deal with this case if any.
For instance when setting the atomic value, is it slower runtime?
It's a good idea - I will be handling topics like that in a separate series though (i.e., one specifically on parallel programming).
Cheers,
--Nick
While it would run slightly slower, you can't focus on speed in a case like this. It's the difference between yielding an accurate result or crashing. The example here may be simple enough that it would likely never crash, but there are numerous cases where you can really destroy your data by not handling threads correctly. You should practice what he shows in the video and watch the one he did on mutices.
great explanation!
Thanks! Glad you thought so!
But why I replace counter += 1 with counter = counter + 1, result is different?
Thanks!
Thank you for the video. However, when I use jthread for the same problem, it doesnt produce correct result. I wonder why that's the case?
This is awesome
cool video, thank you
Nice!
Why do you pronounce it stood atomic?
“Stood” is just a common way of pronouncing “std::”