0

Odd even threads without condition variable

Hi Refer code version 2 which asks threads to print odd and even value one by one using condition variable. It works fine and I belive it is good (feel free to share your view if there is any improvement) I was asked to implement it without condition variable. I tried without condition variable and only using mutex as below (code version 1) but it fails. Please suggest. https://sololearn.com/compiler-playground/cQCvnPULVKxD/?ref=app https://sololearn.com/compiler-playground/cYsd3zJciORH/?ref=app

20th Nov 2024, 7:12 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
10 Answers
+ 1
it seems to be working fine for both. code 2 just happen to output alternately while code 1 outputs them by thread. Maybe what is missing in code 1 is thread synchronization, like what you have in code 2 https://www.geeksforgeeks.org/thread-synchronization-in-cpp/ https://chrizog.com/cpp-thread-synchronization
21st Nov 2024, 12:53 AM
Bob_Li
Bob_Li - avatar
+ 1
odd even thread 1 is normal thread behavior. which thread gets run is determined by the os. No synchronization mechanism here. odd even thread 2 have the thread execution synchronized by condition_variable cv and bool isOddTurn. here is an SO topic related to your question. It have a lot of clever solutions https://stackoverflow.com/questions/14641134/printing-odd-and-even-number-printing-alternately-using-threads-in-c I modified one of the answers into the code below: one function version: https://sololearn.com/compiler-playground/crwYlot7C6m3/?ref=app two function version: use unique_lock instead of lock_guard, and an external boolean flag for state checking. https://sololearn.com/compiler-playground/cyjlF2FtkBEK/?ref=app
21st Nov 2024, 4:15 AM
Bob_Li
Bob_Li - avatar
+ 1
Thanks Bob_Li. Will go through it. Many thanks again!
21st Nov 2024, 6:20 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
+ 1
Bob_Li if I am not wrong , probably below line is the culprit here: threads[i] = thread(printConsecutiveNumbers, i, endValue, num); Assume that there are 40 threads and for loop is so quick. It has initialized 0 to 39 thread objects and by that time only 1 to 10 has been printed. Now again for loop in Main thread is quick so that it simply assign i=1 to 39 again but earlier 11 to 39 were discarded. So we got 1 to 10 printed and 11 to 40 lost as another task was assigned to threads in thread pool
22nd Nov 2024, 12:07 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
+ 1
Hi @Bob_Li I tried your solution related to one function on other platform. I tried with thread counts as 40 and end value as 100 (for which it failed on sololearn platform) on windows 11 with Visual Studio 2019 and it works. I do understand performs is slow and definitely will take more time and it took as expected. What I am now wondering is why it is not overwriting the threads task. Anyway, it is something to think of. But I appreciate your support and thanks a lot for sharing the code which worked as a food of thought. Many thanks...!
24th Nov 2024, 5:05 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
0
Thanks Bob_Li I belive both 1 and 2 are having synchronization implemented. Just curious why 1 i.e. without condition variable is not printing only thread wise
21st Nov 2024, 4:07 AM
Ketan Lalcheta
Ketan Lalcheta - avatar
0
Seems something is wrong in one function version. Getting inconsistent behavior when num and endvalue is changed to below values: const int num = 40; const int endValue = 100;
21st Nov 2024, 6:47 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
0
maybe there's a limit? Other processes in your device are also using their own threads, so how many is actually available to use could be quite low. You can set a higher number, but it would not necessarily result in better performance. Exceeding the available limit would hand over the switching to the os, so your code goes into undefined behavior territory. Best not to go crazy with it. const int num = thread::hardware_concurrency(); cout << num << endl;
21st Nov 2024, 10:16 PM
Bob_Li
Bob_Li - avatar
0
If it was issue with limitation of hardware, output should be slow I.e. it takes more time due to context switching. Here issue is something else. Probably a dead lock so that it is not able to complete the task itself. Still not sure about the reason of deadlock
22nd Nov 2024, 11:55 AM
Ketan Lalcheta
Ketan Lalcheta - avatar
0
I'm not very familiar with hardware level operations, so I can't say for sure. But it's good to know that high thread counts can result in unpredictable behavior so we can be cautious when creating threads.
22nd Nov 2024, 12:25 PM
Bob_Li
Bob_Li - avatar