Fascinating stuff, man. Thank you very much. I'd love to see you continue this series touching on coroutines [also that stop_token, stop_source, etc...] and then going through some of NVIDIA's stdexec implementation examples. Their stdexec is probably gonna become C++'s Executors by C++26, I presume [keyword: P2300] Also, if you were to put out any paid course on any of the common platforms I'd be the first buyer. I came for your old good CUDA stuff and stayed for the great C++ stuff. Greetings from Germany!
Hello Nick, I have a question about the blocking code. What is the purpose of the attribute volatile for the sink variable? Thank you for your great lessons, Simone
it's largely there to prevent the int from being optimized in some way by the compiler that differs from the intent of the benchmark since it marks that writes to this int could have side effects. Reading the C++ standard more, it might not be necessary in this case in the due to the presence of the mutex lock/unlock with release-acquire synchronization which would likely prevent the optimization away/hoisting of loads/stores for sink within the anyway loop). Fortunately, the assembly w/ and w/o are almost identical since it's just an increment of an int being performed.
I think, expected = sink.load() should be inside do..while loop, please see the video at 4.27, because if some other thread updated the sink, then this thread will never able to update the sink.
Never is not accurate, when expected is updated by the atomic compare exchange, it's possible that the same thread performs the atomic comparison again prior to any other thread modifying sink. But your logic is correct in that it is possible that the thread can be stuck in the loop indefinitely but such behavior is not necessarily guaranteed.
Fascinating stuff, man. Thank you very much.
I'd love to see you continue this series touching on coroutines [also that stop_token, stop_source, etc...] and then going through some of NVIDIA's stdexec implementation examples. Their stdexec is probably gonna become C++'s Executors by C++26, I presume [keyword: P2300]
Also, if you were to put out any paid course on any of the common platforms I'd be the first buyer. I came for your old good CUDA stuff and stayed for the great C++ stuff.
Greetings from Germany!
Glad you're enjoying the videos - plenty more content to cover :^)
Cheers,
--Nick
Hello Nick, I have a question about the blocking code. What is the purpose of the attribute volatile for the sink variable? Thank you for your great lessons, Simone
it's largely there to prevent the int from being optimized in some way by the compiler that differs from the intent of the benchmark since it marks that writes to this int could have side effects.
Reading the C++ standard more, it might not be necessary in this case in the due to the presence of the mutex lock/unlock with release-acquire synchronization which would likely prevent the optimization away/hoisting of loads/stores for sink within the anyway loop). Fortunately, the assembly w/ and w/o are almost identical since it's just an increment of an int being performed.
I think, expected = sink.load() should be inside do..while loop, please see the video at 4.27, because if some other thread updated the sink, then this thread will never able to update the sink.
Never is not accurate, when expected is updated by the atomic compare exchange, it's possible that the same thread performs the atomic comparison again prior to any other thread modifying sink. But your logic is correct in that it is possible that the thread can be stuck in the loop indefinitely but such behavior is not necessarily guaranteed.