Source code can be found here: code-vault.net... ===== Support us through our store ===== code-vault.net... ===== Check out our website ===== code-vault.net ===== Check out our Discord server ===== discord.code-v...
Thank you, I have found this, and the previous video on conditional variables extremely helpful. My lecture slides are too fast forward but you explain the concepts in a decent depth and speed. P.s. your speech is very clear which is also nice :)
your video is a life saver!! i couldn't understand what my professor lectures in class. But i'm totally with your logic. thank you so much. now i can start working on my homework now
just a simple checking correction: running the code through valgrind --tools=helgrind i found a possible problem in running the broadcast outside of the lock, simply solvable unlocking the mutex after running pthread_cond_broadcast. Hope this is useful =)
thank you for your amazing and helpful videos. I am wondering how in last example 2 cars are in lock? isn't the concept of mutex that only one thread in lock situation and others are waiting?
Yep, you're right. The trick is with the pthread_cond_wait call. Behind the scenes it actually does the following: pthread_mutex_unlock wait_for_signal pthread_mutex_lock And because of that pthread_mutex_unlock that pthread_cond_wait executes other threads are allowed to lock that mutex. This is why you actually have to pass the mutex to pthread_cond_wait
since feuler has broadcasted, all the four car threads are signalled to check the while loop but one car at a time since the car locks the mutex and then the second car comes and so on correct me if I'm wrong
@@CodeVault if on waiting for signal it unlock then 2 case other car can take lock or fuel_filling if other car take lock then program will hault and if fuel_filling will take lock then it will emit signal cond_wait will receive and it will start execution or on recieving signal before taking lock other car can take lock but in any case only one car or fuel_filling can only take lock ??? can u explain this properly
So the Filled fuel ... X is the amount of fuel in the car that gets filled from the fuel tank and the Now left: X is the amount of fuel in the fuel tank that gets filled from somewhere
pthread_cond_signal vs pthread_cond_broadcast seem like great tools depending on your applications. I'm assuming broadcast is mainly used for times when multiple threads are accessing one shared pool/resource and for a threaded pipeline you'd stick with signal? I'm wondering due to a coding assignment for a pipeline that consisted of 4 threads and I assumed 3 mutexes. (read from file > parse characters and process one pattern > parse characters and parse another pattern > output exactly 80 chars from buffer. With a mutex between each part to keep them from speeding ahead) I had assumed only 3 mutexes each between the arrows, but I'm thinking I would need another mutex at the beginning to keep the reading thread from emptying the entire file and then closing the program early.
Usually you use signal when you expect just one thread to start working (in a thread pool for example, when adding a new job to the list). You use broadcast when there's a possibility that the work requires more than 1 thread
01:41 Not fully sure, but it seems like it only awakens 1 car. Note how you initialized 4 cars, and there's only three initializing car prints above the first fueling. I'm guessing that the fueling function printed faster than the slowest car function instead of the conditional signal awakening 2 cars.
Note that the car function only executes once. After the car has been fueled the thread finishes its execution (thus, for the next iteration, we only get 3 messages)
Small question, in the filling_fuel function, should the broadcast/signal be done inside the mutex lock? I think i remember reading somewhere that it was best practice, or does it not matter?
In this specific program it doesn't matter. If you use the mutex standalone (i.e. in a context that doesn't depend on this condition variable)... it will matter when it comes to priority. If the order is: Signal -> Unlock Then both the standalone and the pthread_cond_wait threads have basically the same time to lock the mutex. If the order is: Unlock -> Signal Then that standalone mutex has a biiit more time to lock the mutex (right before that pthread_cond_signal is executed) to lock the mutex. All in all, this priority shouldn't affect your program's correctness, but it's something to keep in mind
If one of the car thread does not get enough fuel and all the fuel-filling iterations are over, how can the waiting thread on the condition be terminated. Is there any giveup/retry logic that can be added for such waiting threads.
You could add a separate thread that simply checks for activity and have the cars always write to some variable the times it started trying to get fuel and got fuel
Would there be any way to use signals to get the result you get with broadcast? I ask because I'm working on a programming assignment with threads and the professor has told us that we can only use wait and signal. We cannot use broadcast.
I don't think there is an easy way without having a counter of how many threads are waiting and simply call pthread_cond_signal in a for loop. Although... usually, you only need to use signal, not broadcast, what is the reason you absolutely need broadcast?
i have one doubt from start out of 4 car only 1 car can have lock so if 1st car take lock and waiting fro cond_wait and its unlock before lock taken by fuel_filling if another car take lock then fuel_filling will also wait for lock then what will happen??
@@CodeVault i was saying like out of 4 car only 1 will be able to reach cond_wait condition right ? bcoz of lock n if it unlock before lock taken by fuel_filling does another thread can also take know is this possible?
No. All of them will, simply because that, when waiting at pthread_cond_wait, the lock gets dropped and other threads can also lock and call pthread_cond_wait
Just like in any other threads. Detachable threads are just non-joinable, but they still share the memory so they still can make use of the tools you use in non-detachable threads
what happens if signal is executed before another thread reaches condition wait? is the condition wait executed or does it wait until another signal is executed while it's waiting?
Could you also make a video on pthread_cond_timedwait(). Also could you help to cover scenario like: Thread2 goes in condition timed wait. Thread 1 takes mutex lock Thread2 pthread_cond_timedout is signalled due to timeout. What would happen in this scenario? As thread1 was still under mutex lock and now thread 2 due to timeout also is now under mutex lock. Is it a deadlock scenario?
Your videos are improving my thinking ability.Thank you ...
Thank you, I have found this, and the previous video on conditional variables extremely helpful. My lecture slides are too fast forward but you explain the concepts in a decent depth and speed.
P.s. your speech is very clear which is also nice :)
Fantastic video to learn such a complex concept.
misto explicat, exact asta fac la facultate. esti un ajutor de nadejde in sesiune.
This is incredible what you are doing now!
Thank you very much for this helpful tutorial
your video is a life saver!! i couldn't understand what my professor lectures in class. But i'm totally with your logic. thank you so much. now i can start working on my homework now
Thank you very much for these excellent quality videos, I have learned a great deal on conditinal variables to start my hw :)
Thank you endlessly.
Thank you so much sir, your videos are very helpful
Great video!! Really helped me to understand the subject better.
it's very useful for me, thank you so much.
Very helpful and quality videos.
Piola👍
Brilliant explanation.
just a simple checking correction: running the code through valgrind --tools=helgrind i found a possible problem in running the broadcast outside of the lock, simply solvable unlocking the mutex after running pthread_cond_broadcast.
Hope this is useful =)
Very helpful thanks 👍
Thank you!
thank you
thank you for your amazing and helpful videos. I am wondering how in last example 2 cars are in lock? isn't the concept of mutex that only one thread in lock situation and others are waiting?
Yep, you're right. The trick is with the pthread_cond_wait call. Behind the scenes it actually does the following:
pthread_mutex_unlock
wait_for_signal
pthread_mutex_lock
And because of that pthread_mutex_unlock that pthread_cond_wait executes other threads are allowed to lock that mutex. This is why you actually have to pass the mutex to pthread_cond_wait
since feuler has broadcasted, all the four car threads are signalled to check the while loop but one car at a time since the car locks the mutex and then the second car comes and so on
correct me if I'm wrong
@@CodeVault if on waiting for signal it unlock then 2 case other car can take lock or fuel_filling
if other car take lock then program will hault and if fuel_filling will take lock then it will emit signal cond_wait will receive and it will start execution or on recieving signal before taking lock other car can take lock but in any case only one car or fuel_filling can only take lock ??? can u explain this properly
So the Filled fuel ... X is the amount of fuel in the car that gets filled from the fuel tank
and the Now left: X is the amount of fuel in the fuel tank that gets filled from somewhere
pthread_cond_signal vs pthread_cond_broadcast seem like great tools depending on your applications. I'm assuming broadcast is mainly used for times when multiple threads are accessing one shared pool/resource and for a threaded pipeline you'd stick with signal?
I'm wondering due to a coding assignment for a pipeline that consisted of 4 threads and I assumed 3 mutexes. (read from file > parse characters and process one pattern > parse characters and parse another pattern > output exactly 80 chars from buffer. With a mutex between each part to keep them from speeding ahead) I had assumed only 3 mutexes each between the arrows, but I'm thinking I would need another mutex at the beginning to keep the reading thread from emptying the entire file and then closing the program early.
Usually you use signal when you expect just one thread to start working (in a thread pool for example, when adding a new job to the list). You use broadcast when there's a possibility that the work requires more than 1 thread
awesome
01:41 Not fully sure, but it seems like it only awakens 1 car. Note how you initialized 4 cars, and there's only three initializing car prints above the first fueling. I'm guessing that the fueling function printed faster than the slowest car function instead of the conditional signal awakening 2 cars.
Note that the car function only executes once. After the car has been fueled the thread finishes its execution (thus, for the next iteration, we only get 3 messages)
Small question, in the filling_fuel function, should the broadcast/signal be done inside the mutex lock? I think i remember reading somewhere that it was best practice, or does it not matter?
In this specific program it doesn't matter. If you use the mutex standalone (i.e. in a context that doesn't depend on this condition variable)... it will matter when it comes to priority.
If the order is: Signal -> Unlock
Then both the standalone and the pthread_cond_wait threads have basically the same time to lock the mutex.
If the order is: Unlock -> Signal
Then that standalone mutex has a biiit more time to lock the mutex (right before that pthread_cond_signal is executed) to lock the mutex.
All in all, this priority shouldn't affect your program's correctness, but it's something to keep in mind
@@CodeVault Makes sense, thank you!
If one of the car thread does not get enough fuel and all the fuel-filling iterations are over, how can the waiting thread on the condition be terminated. Is there any giveup/retry logic that can be added for such waiting threads.
You could add a separate thread that simply checks for activity and have the cars always write to some variable the times it started trying to get fuel and got fuel
Just wondering why in the last example, after filled 30, not 4 thread goes in (2 first time and 2 signaled)
That is because the car threads were able to lock the mutex first due to the broadcast (to check once) before letting the other fuel thread execute
Would there be any way to use signals to get the result you get with broadcast? I ask because I'm working on a programming assignment with threads and the professor has told us that we can only use wait and signal. We cannot use broadcast.
I don't think there is an easy way without having a counter of how many threads are waiting and simply call pthread_cond_signal in a for loop. Although... usually, you only need to use signal, not broadcast, what is the reason you absolutely need broadcast?
i have one doubt from start out of 4 car only 1 car can have lock so if 1st car take lock and waiting fro cond_wait and its unlock before lock taken by fuel_filling if another car take lock then fuel_filling will also wait for lock then what will happen??
When calling cond_wait the mutex actually gets unlocked so others can access it. The thread relocks the mutex once signal or broadcast is called
@@CodeVault i was saying like out of 4 car only 1 will be able to reach cond_wait condition right ? bcoz of lock
n if it unlock before lock taken by fuel_filling does another thread can also take know is this possible?
No. All of them will, simply because that, when waiting at pthread_cond_wait, the lock gets dropped and other threads can also lock and call pthread_cond_wait
How to use conditional variable in detachable threads??
Just like in any other threads. Detachable threads are just non-joinable, but they still share the memory so they still can make use of the tools you use in non-detachable threads
@@CodeVault I have run the code successfully now. Thank you for your support
what happens if signal is executed before another thread reaches condition wait? is the condition wait executed or does it wait until another signal is executed while it's waiting?
It should wait until another signal gets executed. Here are the docs: linux.die.net/man/3/pthread_cond_signal
@@CodeVault thank you, uni slides were iffy about it, btw I think these tutorials are top 1%
Could you also make a video on pthread_cond_timedwait().
Also could you help to cover scenario like:
Thread2 goes in condition timed wait.
Thread 1 takes mutex lock
Thread2 pthread_cond_timedout is signalled due to timeout.
What would happen in this scenario?
As thread1 was still under mutex lock and now thread 2 due to timeout also is now under mutex lock.
Is it a deadlock scenario?