Thank you so much, these are the highest quality C tutorials on youtube. Very underrated channel, you're an excellent teacher, please continue teaching!
I dont mean to be offtopic but does someone know of a method to get back into an Instagram account? I was dumb lost my password. I appreciate any help you can offer me!
@Samuel Lionel Thanks for your reply. I found the site through google and I'm waiting for the hacking stuff atm. Looks like it's gonna take a while so I will get back to you later with my results.
16:35 The difference between pthread_cond_signal() and pthread_cond_broadcast() lies in what happens if multiple threads are blocked in pthread_cond_wait(). With pthread_cond_signal(), we are simply guaranteed that at least one of the blocked threads is woken up; with pthread_cond_broadcast(), all blocked threads are woken up.
Sergiu, I can't thank you enough for this video. My OS professor really struggled to explain this topic, so I left the class without any intuition as to why condition variables were needed. Your example at 8:16 made my jaw drop, furthermore, your description of signalling being an indication that a condition's result *may* have changed really cleared things up for me. This is the second video of yours that I've watched (the first being pthread Barriers). It's safe to say that I'll be subscribing to your channel. Thank you for sharing your knowledge of these complex topics, you make them much easier to understand, and for that I'm grateful.
I was looking at concurrency stuff again earlier today and remembered this video. Just wanted to say thanks again, I've since graduated and have been working at a big tech company :)
I have been searching since yesterday on condition variables so i can understand what they are exactly and how they work, and i can say it's the most helpful thing! Cheers from Cyprus keep on the good work.
this is so so so good. usually, guys are speaking way fast because they don't understand that it's hard to follow the concepts for someone brand new being exposed to the subject. you really have a gift for teaching. People think just because they know a subject matter that they can become teachers but that's is not true. It takes special skills to be able to relate a material to someone else that is brand new to the matter at hand. Just a million thanks
You have successfully explained something that my professors, articles online, a textbook, and documentation couldn't explain well. And concisely too! These videos are amazing, please make more!
Wow well done! You did an amazing job explaining that. I love how you fast forwarded the more tedious coding we're already familiar with and really took your time with the nuances of condition variables
I made a nice improvements to this code. maybe wanna have a look? I set a max size of the car's fuel tank and made sure the fuel tank was full before the car leaves the filling station and also made the the filling station only signal the car only when there's enough for the car(i.e fuel > 40) at least to help improve understanding
You are an awesome teacher! keep on these tutorials coming :)) a question: is this the concept of producer/consumer? as I understand in this case, producer is the fuelFilling and the consumer is the car, right?
I guess you can say that. Usually it has to do with entities in the sense that producers create entities that consumers have to process. Here you only have a number. Here's the video on the producer/consumer problem: code-vault.net/lesson/tlu0jq32v9:1609364042686
I was actually curious on that topic and researched a bit. As it turns out, it doesn't really matter. You'd think that, because of the multithreaded nature of the program, there's a chance another thread would lock the mutex right after the unlock and right before the lock inside pthread_cond_wait. While it can happen, that's why we do a check every time we get past the pthread_cond_wait. Additionally, even if we have the order reversed (first signal then unlock), there's a chance another thread locks the mutex right after we call pthread_cond_signal. So either way, you can run in the same issue. Maybe you have another reason for it that I overlooked
Great Instructional Videos. Very helpful. Question: Could you have also solved the problem by putting the Mutex lock AFTER you check that fuel is above 40? Then the car would not lock the mutex unless there was enough fuel. With one car this would work.
No. That would cause a race condition on the fuel variable. You have to lock the mutex before checking simply because some threads might try to write to that fuel variable in the meantime. So, you must make sure, no other threads are currently trying to write to it.
It's already up ;) You can check it out on our website: code-vault.net/lesson/18ec1942c2da46840693efe9b5203fac I don't usually name things "part 2" so that others searching for this topic will still find that video useful.
Great content bro. You must be very smart to be able to come up with these great examples. Do you know where I can find some problems to practice this?
I don't have a special website. But it's easy to come up with one. Just think about a "resource" that can be "used" by many and can be replenished by many others. That's basically it.
in the fuel filling function, if you don't sleep after a single loop, it completes all 5 iterations before it signals the car routine thread. why's that so?? the signal is in the for loop. and since the code executes for each iterations.
Thank you for the video! One question, however, isn't it better for the call to pthread_cond_signal to be on a thread that owns the mutex, meaning calling pthread_cond_signal before unlocking? The man page recommends this for a more predictable scheduling. Thank you again.
I actually researched this a bit and, from what I can tell, it really doesn't matter in this case because the the only thread that could unlock this mutex is the one we are signaling. In cases where you have some external thread that uses that mutex without the condition variable then, yes, it would be recommended to do so since the signaled thread would have a bigger chance of locking the mutex than the external ones. But all in all, it wouldn't impact the correctness of the code.
Thanks for the great video. Quick question, shouldn't the condition variable be signalled and then the mutex be released? If there is priority inheritance due to holding the mutex, we still hold the elevated priority while signalling the condition variable but if we do release of mutex first, then the inherited priority would get lost and our thread may get pre-empted out before getting a chance to signal the condition variable.
I'm new to C, trying my best to learn the language to the fullest. But I'm having a hard time learning these concepts, I feel like I'm missing something. So if possible, can anyone please tell me of roadmap to C that I should follow? I appreciate the effort that went into this video.
The concepts taught in this video are a bit more advanced. I suggest starting out with a simple pet project that you evolve over time. It could a simple calculator that uses the terminal for user input/output or some sort of simple game. Once you have worked a bit with these you can come back to these videos and possibly improve your project
Thanks for the video! Clarified a few things for me, although i still have one thing that remains unclear: shouldn't the pthread_cond_signal() be called by the thread when it STILL HAS the lock on the MUTEX?....in your example you do it after UNLOCKING.
The order doesn't really matter since pthread_cond_wait does call internally pthread_mutex_lock so it will wait for the mutex to be unlocked. AND if there are any external threads waiting on the lock then that order gives a better chance for that external thread to lock the mutex first (before the thread that called pthread_cond_wait). But this shouldn't change the correctness of your program.
Because, even when reading a variable a race condition could occur. If one process would write and our process would read then, we would be reading old data. And, if by chance, the writing process writes to that variable right after checking it then we would encounter a race condition and our program would be doing something completely unexpected
Is it possible to pass an array of function pointers, kinda like this thread is doing this series of jobs or before joining pass it another function? EDIT: I tried passing a struct thread_jobs with the job count and a pointer to a function pointer and initialized the struct with an array of function pointers made on the stack of main, passed the struct as an argument and it successfully serialized a series of jobs for each thread. ofc, the function pointer's return type and args are static but as a POC it works.
Classic consumer - producer problem, I would much rather see you solve it as an endless simulation (constantly fueling cars and when fuel too low in the main tank -> fill it up again;
What about protecting the fuel integer from being cached in any of the cpu caches? I don't think a mutex is sufficient for that, and I'm told that volatile is not enough either.
You don't have to worry about this issue. CPUs already handle synchronization primitives (such as semaphores, condition variables, mutexes ... ) in such a way that their cache will be consistent with memory. Whenever a write occurs to the fuel integer it invalidates all the other cores' caches for that variable's value
I'm sure this gets said a lot, but this pthread playlist has legitimately helped me more than a semester of class. Thank you
Thank you so much, these are the highest quality C tutorials on youtube. Very underrated channel, you're an excellent teacher, please continue teaching!
I dont mean to be offtopic but does someone know of a method to get back into an Instagram account?
I was dumb lost my password. I appreciate any help you can offer me!
@Trevor Joel instablaster :)
@Samuel Lionel Thanks for your reply. I found the site through google and I'm waiting for the hacking stuff atm.
Looks like it's gonna take a while so I will get back to you later with my results.
16:35 The difference between pthread_cond_signal() and pthread_cond_broadcast() lies in
what happens if multiple threads are blocked in pthread_cond_wait(). With
pthread_cond_signal(), we are simply guaranteed that at least one of the blocked
threads is woken up; with pthread_cond_broadcast(), all blocked threads are woken up.
4 years later and these videos are still helping a lot of students all around the world. thank you!!
I think you have the best teaching skills I've seen in all my school and University years. Thanks for educating us!
I cannot describe my gratitude my man. Solid high quality teaching. You're being loved from Turkiye.
Sergiu, I can't thank you enough for this video. My OS professor really struggled to explain this topic, so I left the class without any intuition as to why condition variables were needed. Your example at 8:16 made my jaw drop, furthermore, your description of signalling being an indication that a condition's result *may* have changed really cleared things up for me.
This is the second video of yours that I've watched (the first being pthread Barriers). It's safe to say that I'll be subscribing to your channel. Thank you for sharing your knowledge of these complex topics, you make them much easier to understand, and for that I'm grateful.
I was looking at concurrency stuff again earlier today and remembered this video. Just wanted to say thanks again, I've since graduated and have been working at a big tech company :)
I have been searching since yesterday on condition variables so i can understand what they are exactly and how they work, and i can say it's the most helpful thing! Cheers from Cyprus keep on the good work.
lmao I am also from Cyprus are you studying on ucy?
My college teachers should teach like you , our lives would be fantastic then
this is so so so good. usually, guys are speaking way fast because they don't understand that it's hard to follow the concepts for someone brand new being exposed to the subject. you really have a gift for teaching. People think just because they know a subject matter that they can become teachers but that's is not true. It takes special skills to be able to relate a material to someone else that is brand new to the matter at hand. Just a million thanks
15:37 Thanks you for telling us about the implicit unlock and relock.
Really glad I found this channel, the examples are always on point and a concept that seemed abstract previously makes perfect sense now!
You have successfully explained something that my professors, articles online, a textbook, and documentation couldn't explain well. And concisely too! These videos are amazing, please make more!
got your videos opened in one window and VS in another window working my CS 344 final assignment. My guy, you're the reason i'm passing.
Thank you so much for these. You have no idea how much you have helped me with these C videos. God bless you.
Wow well done! You did an amazing job explaining that. I love how you fast forwarded the more tedious coding we're already familiar with and really took your time with the nuances of condition variables
Thanks a lot for explaining with an example. It really made it a lot easier to understand it's use and how to use it.
best thread playlist s the best I could found in RUclips! Thanks !!
Got a final in 2 days and this was an aspect of synchronization which has been confusing me all semester. Very helpful.
This cleared up so much for me. Thank you very much for posting this!
Thank You! I have been struggling with this whole concept and then found your video! Well explained! :)
You're amazing thank you so much man. Your videos helped me tremendously with our OS and networking classes. Don't stop!
Thank you, this was the only good explanation of condition variables i could find. Very well explained
Brilliant and simple explanation, helped me to untangle my c++ condvars understanding. Many thanks!
clear explanation with simple example, thank you for creating such helpful content
Just great explanation! Can't wait till I got some time to watch your other content. :)
Thanks a lot. It is hard to find people that understand stuff and can explain it properly to others
Thank you for this video. It was presented very cleary and understandably.
You're amazing. Thank you so much for share this knowledge.
It is good for us to learn the concepts and implementation of the linux c!! Thank you!!
Perfect! . Thank you for sharing your experiences.
Thank you. You explained such a complex topic with so much ease. Thanks a lot.
Thanks for this video. Your conceptual explanation is crystal clear !!
The best video on this topic, best wishes for you!
Great video, helped me understand CV's from my OS course.
Big brain explaination. thank you
Great example and great explanation. Thanks!
Thank you so much for this content! Absolutely helpful.
What a good explanation. Thank you!
Excellent example, excellent content. Thank you.
Thank you, it is usefully for my collage work.
Pthreads concepts from 0 to master level. Please continue your contributions to this world. __/\__
Great video man im learning so much from you thank you!
I made a nice improvements to this code. maybe wanna have a look? I set a max size of the car's fuel tank and made sure the fuel tank was full before the car leaves the filling station and also made the the filling station only signal the car only when there's enough for the car(i.e fuel > 40) at least to help improve understanding
Thank you very much for these videos, you have helped me a lot.
Great explanation! Keep up the good work!
Thank you, I hope it will help my in my exam tomorrow, I will let you know
I passed, wonderful explanations, thank you
Thank you!! Great help for my operating systems class
Thank you so much for your explanation! It helped a lot.
You are an awesome teacher! keep on these tutorials coming :))
a question: is this the concept of producer/consumer? as I understand in this case, producer is the fuelFilling and the consumer is the car, right?
I guess you can say that. Usually it has to do with entities in the sense that producers create entities that consumers have to process. Here you only have a number. Here's the video on the producer/consumer problem: code-vault.net/lesson/tlu0jq32v9:1609364042686
Dude, you're amazing! Thank you so much!
thank you so much for your videos, they're amazing!
Great video, thank you for sharing! I think it's better to unlock the mutex after signaling the condition variable. Again many thanks!
I was actually curious on that topic and researched a bit. As it turns out, it doesn't really matter. You'd think that, because of the multithreaded nature of the program, there's a chance another thread would lock the mutex right after the unlock and right before the lock inside pthread_cond_wait. While it can happen, that's why we do a check every time we get past the pthread_cond_wait.
Additionally, even if we have the order reversed (first signal then unlock), there's a chance another thread locks the mutex right after we call pthread_cond_signal. So either way, you can run in the same issue.
Maybe you have another reason for it that I overlooked
Man I really appreciate the help, you really know how to help
Nice explanation Thank you...
Thank you!! you did what my teacher couldn't
Great Instructional Videos. Very helpful. Question: Could you have also solved the problem by putting the Mutex lock AFTER you check that fuel is above 40? Then the car would not lock the mutex unless there was enough fuel. With one car this would work.
No. That would cause a race condition on the fuel variable. You have to lock the mutex before checking simply because some threads might try to write to that fuel variable in the meantime. So, you must make sure, no other threads are currently trying to write to it.
Best video ever. Keep up the good work man
when will the second part of this video be up? great explanation
It's already up ;)
You can check it out on our website: code-vault.net/lesson/18ec1942c2da46840693efe9b5203fac
I don't usually name things "part 2" so that others searching for this topic will still find that video useful.
@@CodeVault thanks alot
thank you !! Great example!! Helpfull very helpfulllll
Awesome explanation ! Thanks
I really hope you will make a similar series with Go
The more I look into Go the more interesting it is. I might start learning it and then make some videos about it in the future
Te la rifas mi estimado :33. Muchas gracias por tus videos, me estan ayudando mucho :'3
I'll only say just one word: Perfect!
Great content bro. You must be very smart to be able to come up with these great examples. Do you know where I can find some problems to practice this?
I don't have a special website. But it's easy to come up with one. Just think about a "resource" that can be "used" by many and can be replenished by many others. That's basically it.
in the fuel filling function, if you don't sleep after a single loop, it completes all 5 iterations before it signals the car routine thread. why's that so?? the signal is in the for loop. and since the code executes for each iterations.
Plain and simple explaning, great job! Also i like the typing sound, can you share what keyboard and switches you use? Thanks
Thanks! It's a Corsair K63 with Cherry MX reds. Although I don't recommend it, the key caps break very easily.
Great explanation!
Thank you for the video! One question, however, isn't it better for the call to pthread_cond_signal to be on a thread that owns the mutex, meaning calling pthread_cond_signal before unlocking? The man page recommends this for a more predictable scheduling. Thank you again.
I actually researched this a bit and, from what I can tell, it really doesn't matter in this case because the the only thread that could unlock this mutex is the one we are signaling. In cases where you have some external thread that uses that mutex without the condition variable then, yes, it would be recommended to do so since the signaled thread would have a bigger chance of locking the mutex than the external ones. But all in all, it wouldn't impact the correctness of the code.
@@CodeVault thank you for taking your time to respond, and for the response as well!
Awesome explanation
Great video! Thanks!
Genius teaching!
I 'cond' wait to start practising with pthread_cond.
I'll be here all week folks. ;)
very helpful, thank you very much :D
I frickin love u
Thanks for the great video. Quick question, shouldn't the condition variable be signalled and then the mutex be released? If there is priority inheritance due to holding the mutex, we still hold the elevated priority while signalling the condition variable but if we do release of mutex first, then the inherited priority would get lost and our thread may get pre-empted out before getting a chance to signal the condition variable.
It was so long ago, I don't fully remember. I tested the difference between the two and, in practice, didn't see a difference
I'm new to C, trying my best to learn the language to the fullest. But I'm having a hard time learning these concepts, I feel like I'm missing something. So if possible, can anyone please tell me of roadmap to C that I should follow?
I appreciate the effort that went into this video.
The concepts taught in this video are a bit more advanced. I suggest starting out with a simple pet project that you evolve over time. It could a simple calculator that uses the terminal for user input/output or some sort of simple game. Once you have worked a bit with these you can come back to these videos and possibly improve your project
Thanks for the response, much appreciate it.
Better quality than my university classes. -__-
Thanks for the video! Clarified a few things for me, although i still have one thing that remains unclear: shouldn't the pthread_cond_signal() be called by the thread when it STILL HAS the lock on the MUTEX?....in your example you do it after UNLOCKING.
The order doesn't really matter since pthread_cond_wait does call internally pthread_mutex_lock so it will wait for the mutex to be unlocked. AND if there are any external threads waiting on the lock then that order gives a better chance for that external thread to lock the mutex first (before the thread that called pthread_cond_wait). But this shouldn't change the correctness of your program.
Thank you great job!
You are the life changer
amazing explanation
9:40 why do we have to lock something when we are checking ? like Couldnt we put line 21 right after the while() loop?
Because, even when reading a variable a race condition could occur. If one process would write and our process would read then, we would be reading old data. And, if by chance, the writing process writes to that variable right after checking it then we would encounter a race condition and our program would be doing something completely unexpected
what an example !!🙂
So helpful, thank you
Very well done thank you !
Nice perception.
Is it possible to pass an array of function pointers, kinda like this thread is doing this series of jobs or before joining pass it another function?
EDIT: I tried passing a struct thread_jobs with the job count and a pointer to a function pointer and initialized the struct with an array of function pointers made on the stack of main, passed the struct as an argument and it successfully serialized a series of jobs for each thread.
ofc, the function pointer's return type and args are static but as a POC it works.
Great tutorial
The best tracher i ever have..
I couldńt find other videos, can You do a monitor implementation ? anyway Thankyou verymuch !
I'll look into it
@@CodeVault Thank you very much thank you
You're the c++ boss!
you are a life saver
Classic consumer - producer problem, I would much rather see you solve it as an endless simulation (constantly fueling cars and when fuel too low in the main tank -> fill it up again;
Very helpful !
Thank you!
I love you bro, are you a teacher ? You are explaining this better than mine
No, I don't teach at any university or school. I just learned by helping a lot of people throughout the years
God sends the Savior, He's the One
THank you
What about protecting the fuel integer from being cached in any of the cpu caches? I don't think a mutex is sufficient for that, and I'm told that volatile is not enough either.
You don't have to worry about this issue. CPUs already handle synchronization primitives (such as semaphores, condition variables, mutexes ... ) in such a way that their cache will be consistent with memory. Whenever a write occurs to the fuel integer it invalidates all the other cores' caches for that variable's value