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 very much! You explained it so well and clearly; when my university lecturer explained it to me, I did not understand anything. I really like your channel.
Great video, explained how lock and unlock work really well. I was having trouble understanding what it was with my professors explanation lol. Thanks for explaining it, you definitely deserve more views and subs!
The operations performed by a thread after acquiring a lock are called "critical section". This helps in achieving thread synchronisation. Thanks for the video!
Can’t thank you enough for your detailed and succinct explanations! When I began diving in to multithreaded programming with C++17 I became overwhelmed pretty quickly
Subscribed to your channel man. Its crazy how you break down everything into making them seem so easy! Much appreciated dude and I really hope more see your channel, much love!
Thanks, for the amazing tutorial. Keep posting the content :) Could you please post one video to print odd-even numbers in a sequence, so it will be more clear regarding the mutex and condition variables?
I want you to know you have taught me more about the C language in 10 minutes than an entire university lecture did in 80 minutes. I need to learn this for a project and you have made my life so much easier. Thank you so much.
I love your videos. Your materials are helping me a lot more than my lecturers do and also you making it simple and more understable. Looking forward to POSIX/ SYS V semaphores. Also I would like to ask will there be coming more materials about pthreads ? ( maybe private data of threads). Best of regards code vault. Keep it up!
Thank you! And yes, the last lessons in the course are not yet decided so will add most of the suggestion from the community there (like this one ;) ).
just a note mutuale exclusion problem can heppen even for single core processors , because when the quantum ends of a processoes , another process can modifie the variable
That's the thing with multi-threaded applications, they are difficult to find the bugs. Since race conditions are not always guaranteed, an issue like what I showed you in the video has a chance of not happening. And maybe on your machine you have less threads and thus lowering the chance even further. Try to run the whole main function in a loop for a few hundred iterations and see if you ever get that number to be different than 200000.
They are basically the same. The first one could technically be faster since it only assigns some values but can only be used. Also, it guarantees that the lock is always initialized
I rewatched the video and I think an explanation of what a mutex is is at the beginning of the video with that "lock" variable example. Maybe I should've went into more detail, but, at the end of the day, for a beginner, I think this explanation is good enough. I might look into an in-depth explanation of the inner workings of the mutex at a future date
Thank you for your great video bro. You save my life !!! Just curious a little bit from the last video. Base on my understanding, Race condition happen when 2 thread read memory at the same time. Is that possible if mutex lock data in exactly same time and race condition happen. If not why?
First things first: a race condition happens only in two cases: 1) You have one thread writing a piece of data while other threads are reading it 2) You have multiple threads writing the same piece of data Two threads reading the same piece of data won't cause a race condition. Although with mutexes a read and write could happen at the same time, they are designed so that each read and write on them is atomic, meaning there's no way other threads could read the data while another is in the process of writing it (only before it wrote to it or after that)
i have encounter an error regarding pthread_mutex_destroy(&mutex, NULL); but they are not receiving the int type for this function it just takes the refernce that's it. Hope u understand what i am trying to convey.
Bro small problem with your code.I took this as a refresher to threads.Locking and unlocking the mutex in each iteration of the loop introduces unnecessary overhead and reduces the potential benefits of multithreading. A better way is to lock and unlock it outside the loop.Anyway thanks for the video bro
Of course. But this was a short explanation and I wanted to show that the mutexes work even if multiple loops are executing at the same time. In a production environment, this would be very inefficient indeed
I'm not really a fan of the whole monetization endeavor on TH-cam. Trying to move away from this business model to one that more benefits the audience. (Like our store that you can check out here: code-vault.net/shop )
Race conditions can also occur on single core processors like if we consider concurrent CPU and the operations are read, increment and write. So lets say P1 starts first then P1 reads increments and then it is preempted by another process P2, then P2 does read, increment and then it is preempted by P1. Now P1 writes the value and exits after which P2 comes and writes its value thus there is a race condition
I dont know its bc im bad at C, but I dont understand how the mutex helps, like, it allows to send a mail, sends a mail, then closes again, is that so? Did I get it? How does that help?
say in the routine() function I had 3 different operations, op1, op2, op3. I place a mutex_lock before op1, mutex_unlock after op1. Assume 3 threads. Will the other threads execute op2, and op3 when op1 is under lock ?
No, they won't. All threads will wait at the mutex_lock instruction until the lock is unlocked. Though, this still allows for race conditions on op2 and op3
It's just some attributes that you can set for the thread to run in a specific way. You can read more on this here: linux.die.net/man/3/pthread_attr_init
I purely watched this playlist to understand what the heck my OS prof was teaching when she taught us semaphores (although for processes) and I couldn't understand at that time. Loved it !
In modern software you should almost always use a mutex (unless you are working with something at an OS level and it's critical that the lock locks/unlocks quickly enough)
You could do that (and I suggest you actually try + print out which thread incremented the value). But what you'll notice is that if you put the mutex lock/unlock outside the for loop, the thread that locks the mutex will make ALL the add operation and only after that will a different be able to make any add operation on that variable. So, while it's possible. It's not what you're looking for usually.
Well, init is surely needed when using a mutex. Although, probably, since the mutex is global in this video it gets its members automatically initialized to 0 and I think that coincides with what pthread_mutex_init sets the values to. If you try to use the a local mutex I think you'd have issues without the init function call. The pthread_mutex_destroy is not 100% necessary on some architectures but it's good practice
Maybe a minor misstatement when you say race conditions only happen on multicore systems. I think race conditions can also happen on one core processors. You could save your mails in thread 1 context switch to thread 2 and finish loop then go back to 1 and finish, then your result would only be 1,000,000 on write back. Great content though. Love this playlist.
Yes, it's definitely wrong. Race conditions can happen on any system. It's just much much rare to happen on single-core processors as the context switch would have to happen right between an assignment (which, from what I recall, is a very low chance). Maybe I will make a video on this topic to investigate what is the chance of that happening and whatnot
So if we are locking and unlocking in this manner it means each thread is running one after the other never at the same time, right? So isnt this the same as not using threads at all? And if we have to lock and unlock to avoid data races then how are threads useful? Anybody know what I'm missing here ? Thank you for your videos, super helpful as always!
Do I need mutex if one thread is changing the variable, and the other only reads it ? Race condition will not occur, but there can be a collision in access. There are different opinions about the need for mutex. What's yours ?
I showed in the first video of the playlist how to compile and run the code: code-vault.net/lesson/18ec1942c2da46840693efe9b51d86a8 All of the code I am presenting here is ran under Linux by the way
This man deserves so many more views and subscribers. So well explained. My professors need to learn from him on how to teach.
yup
i reply for the referencement
Exactly
This is something random but it's so attractive seeing someone being so smart
Thanks haha
This man is practically the best teacher I've ever had. Thank you SOOO MUCH.
Man, you are an absolute legend! Thank you so much for uploading this.
Thank you very much! You explained it so well and clearly; when my university lecturer explained it to me, I did not understand anything. I really like your channel.
you should train professors on how to teach
Thanks for explaining, it was very easy to understand.
I bet you are not even close to understand how good you've done for humanity since you started this channel. Thank you very much.
This man is practically the best teacher! Sub!
Man, you really make C look very simple and lovable.
The lock variable + if block example is the best example I have even seen for this Mutex topic
Great video, explained how lock and unlock work really well. I was having trouble understanding what it was with my professors explanation lol. Thanks for explaining it, you definitely deserve more views and subs!
thank you really , you are better than almost all the teachers in this world...
all the respect
The operations performed by a thread after acquiring a lock are called "critical section". This helps in achieving thread synchronisation. Thanks for the video!
you are a gem! Thank you for the videos.
PERFECT! looking forward to see a video about spinlock!
Thank you for the practical Mutual Exclusion video.
Mutual Exception.
I really enjoy your videos, thank you
Could you make a video about Condition Variables with threads?
Will do
Thank you sir , I appreciate your help !
Thanks for making these amazing tutorials. You earned a sub
Can’t thank you enough for your detailed and succinct explanations! When I began diving in to multithreaded programming with C++17 I became overwhelmed pretty quickly
Very useful video! Thank you!
Really useful videos, just as im learning this at school :D
Love your Videos
Fantastic explanation!!! Thanks
Your video is the best. thx
I'd be screwed if it wasn't for many of your c videos
Thank you.
Subscribed to your channel man. Its crazy how you break down everything into making them seem so easy! Much appreciated dude and I really hope more see your channel, much love!
Thank you
good explanation!
Thanks, for the amazing tutorial. Keep posting the content :)
Could you please post one video to print odd-even numbers in a sequence, so it will be more clear regarding the mutex and condition variables?
I want you to know you have taught me more about the C language in 10 minutes than an entire university lecture did in 80 minutes. I need to learn this for a project and you have made my life so much easier. Thank you so much.
Thank you! :)
God send savior, HE's the ONE
Thanks for the wonderful video. I have a question. What happens if thread 1 throws an error before the unlock? Will thread 2 wait forever?
The lock is released, so thread 2 won't wait forever
arrayyy u r great ji😍
Hello. This is one of the greatest tutorials I've seen. I will be watching the whole playlist, thank you for your hard work and skill in education.
You're an AMAZING teacher, Sir. Thanks for this. Subscribed!
great video! thanks!!!! very good job! greetings from germany
I love your videos. Your materials are helping me a lot more than my lecturers do and also you making it simple and more understable. Looking forward to POSIX/ SYS V semaphores. Also I would like to ask will there be coming more materials about pthreads ? ( maybe private data of threads). Best of regards code vault. Keep it up!
Thank you! And yes, the last lessons in the course are not yet decided so will add most of the suggestion from the community there (like this one ;) ).
You saved alot of work and misunderstanding with the threads videos. Thanks alot
you are a god
dude you’re the best. Thank you so much for making these videos
Your classes are amazing! All of them! Just one thing, I think that when you say race condition, the correct term is data race. Cheers!
just a note mutuale exclusion problem can heppen even for single core processors , because when the quantum ends of a processoes , another process can modifie the variable
AMAZING TEACHER!!!!!!!!!!!!!!!!!! THANK YOU!!!
BRO your tutorials bring me through my whole semester
thank you so much you should be the one teaching me operating systems not francesco bernoulli
Can we say that mutex locking forces the multithreading routine into serial?
Yes. Basically the critical section that is surrounded by a mutex lock/unlock will always be serially executed
Once again, TH-cam saves my homework. Thank you!
race cond can also happen in single core if interrupts are enabledand a variable is modified.
Best course on Multithreading!!
I am doing the exact same thing but get 2.000.000, why?
I mean before using mutex, I was already getting 2.000.000.
That's the thing with multi-threaded applications, they are difficult to find the bugs. Since race conditions are not always guaranteed, an issue like what I showed you in the video has a chance of not happening. And maybe on your machine you have less threads and thus lowering the chance even further. Try to run the whole main function in a loop for a few hundred iterations and see if you ever get that number to be different than 200000.
man, i wanna be your thread. such a good explanation
Your a gem!
If I could hit the like button more than 1000 times
Apparently there's another way of initializing a pthread_mutex:
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
I wonder what the difference is
They are basically the same. The first one could technically be faster since it only assigns some values but can only be used. Also, it guarantees that the lock is always initialized
Man you are a God, thanks to sharing this with us!
You are a gem 🙏🏻
i comment for the referencement, you're a good guy
Could you make a video about semaphores and pointing the differences between it and mutexes' use cases?
Yep, semaphores and barriers are also planned for this course
This is an example of how and why to use a mutex, but doesn't make an effort to explain what a mutex is
I rewatched the video and I think an explanation of what a mutex is is at the beginning of the video with that "lock" variable example. Maybe I should've went into more detail, but, at the end of the day, for a beginner, I think this explanation is good enough. I might look into an in-depth explanation of the inner workings of the mutex at a future date
Thank you for your great video bro. You save my life !!!
Just curious a little bit from the last video. Base on my understanding, Race condition happen when 2 thread read memory at the same time. Is that possible if mutex lock data in exactly same time and race condition happen. If not why?
First things first: a race condition happens only in two cases:
1) You have one thread writing a piece of data while other threads are reading it
2) You have multiple threads writing the same piece of data
Two threads reading the same piece of data won't cause a race condition.
Although with mutexes a read and write could happen at the same time, they are designed so that each read and write on them is atomic, meaning there's no way other threads could read the data while another is in the process of writing it (only before it wrote to it or after that)
from this part there is a question in exam ppr
i have encounter an error regarding pthread_mutex_destroy(&mutex, NULL);
but they are not receiving the int type for this function it just takes the refernce that's it. Hope u understand what i am trying to convey.
The pthread_mutex_destroy only has one parameter, the mutex you are trying to destroy
Bro small problem with your code.I took this as a refresher to threads.Locking and unlocking the mutex in each iteration of the loop introduces unnecessary overhead and reduces the potential benefits of multithreading. A better way is to lock and unlock it outside the loop.Anyway thanks for the video bro
Of course. But this was a short explanation and I wanted to show that the mutexes work even if multiple loops are executing at the same time. In a production environment, this would be very inefficient indeed
You should put more ads in your video so it can benefit you aswell
I'm not really a fan of the whole monetization endeavor on TH-cam. Trying to move away from this business model to one that more benefits the audience. (Like our store that you can check out here: code-vault.net/shop )
@@CodeVault You are quite a saint man, you saved my semester. Just wanted you to know
Thank you so much for the video!
Race conditions can also occur on single core processors like if we consider concurrent CPU and the operations are read, increment and write. So lets say P1 starts first then P1 reads increments and then it is preempted by another process P2, then P2 does read, increment and then it is preempted by P1. Now P1 writes the value and exits after which P2 comes and writes its value thus there is a race condition
You're right, I didn't want to go into much detail regarding this and gave a simple (albeit wrong) explanation
I hope my current professor is you..
I think using lock the execution of the program would be slower, but that is not important . More important is avoiding race condition
Yes but doesn't that mean we're forcing multithreading program into serial program?
I dont know its bc im bad at C, but I dont understand how the mutex helps, like, it allows to send a mail, sends a mail, then closes again, is that so? Did I get it? How does that help?
It's basically a way to tell other threads if there's one thread already using that mutex (aka executing some critical part of the code)
thank you for this playlist
Ty for the awesome videos!
This man is amazing! I wish he had merch, I would love to rock a code vault T-Shirt or Hoody
Haha, thanks. I will think about launching some merch if enough people want them
say in the routine() function I had 3 different operations, op1, op2, op3. I place a mutex_lock before op1, mutex_unlock after op1. Assume 3 threads. Will the other threads execute op2, and op3 when op1 is under lock ?
No, they won't. All threads will wait at the mutex_lock instruction until the lock is unlocked. Though, this still allows for race conditions on op2 and op3
Thanks for the great explanation!
Thank you SOOO MUCH.
What is use case of second parameter of NULL when I create a thread. What are the use case i can change from NULL to some other?
It's just some attributes that you can set for the thread to run in a specific way. You can read more on this here: linux.die.net/man/3/pthread_attr_init
I purely watched this playlist to understand what the heck my OS prof was teaching when she taught us semaphores (although for processes) and I couldn't understand at that time. Loved it !
amazing explanation.
Perfect!!!!
Good stuff my friend
when should one use a spinlock over a mutex
In modern software you should almost always use a mutex (unless you are working with something at an OS level and it's critical that the lock locks/unlocks quickly enough)
good explanation bro
Greate video that makes me want to migrate from windows to linux😂
For development it's definitely a must. Either to Linux or Mac... Windows is not great for development
Is having the mutex locks and unlock inside the for-loop the only solution? Could the mutex's have been on the outside of the for-loop?
You could do that (and I suggest you actually try + print out which thread incremented the value). But what you'll notice is that if you put the mutex lock/unlock outside the for loop, the thread that locks the mutex will make ALL the add operation and only after that will a different be able to make any add operation on that variable.
So, while it's possible. It's not what you're looking for usually.
Even if I comment mutex_init and mutex_destroy, i can able to see mutex lock/unlock is working. Then what is the use of init/destroy function???
Well, init is surely needed when using a mutex. Although, probably, since the mutex is global in this video it gets its members automatically initialized to 0 and I think that coincides with what pthread_mutex_init sets the values to. If you try to use the a local mutex I think you'd have issues without the init function call. The pthread_mutex_destroy is not 100% necessary on some architectures but it's good practice
@@CodeVault Thank you for your clarity.
Its incredible, I'm French but I understood perfectly this video, thanks you
Maybe a minor misstatement when you say race conditions only happen on multicore systems. I think race conditions can also happen on one core processors. You could save your mails in thread 1 context switch to thread 2 and finish loop then go back to 1 and finish, then your result would only be 1,000,000 on write back. Great content though. Love this playlist.
Yes, it's definitely wrong. Race conditions can happen on any system. It's just much much rare to happen on single-core processors as the context switch would have to happen right between an assignment (which, from what I recall, is a very low chance). Maybe I will make a video on this topic to investigate what is the chance of that happening and whatnot
@@CodeVault that would be awesome 👍🏻
I wish you were one of my professors. Every time I watch a video from you I get excited to code again.
Great job. Explanations are easy and clear, very useful information. Thanks a lot!!!
You make complex things more easier, great job !! thank you.
So if we are locking and unlocking in this manner it means each thread is running one after the other never at the same time, right? So isnt this the same as not using threads at all? And if we have to lock and unlock to avoid data races then how are threads useful? Anybody know what I'm missing here ? Thank you for your videos, super helpful as always!
No, what you just described would be the case if he locked OUTSIDE of the loop
@@Ellen_Musik okay thank you!
Do I need mutex if one thread is changing the variable, and the other only reads it ? Race condition will not occur, but there can be a collision in access. There are different opinions about the need for mutex. What's yours ?
You will still get a race condition. I think that's called a dirty read. It depends on the situation if you need a mutex
2:09 what if the threads met a race condition at reading lock?
locks are thread-safe at the OS level
Sir, what steps are you following to run the code?
I showed in the first video of the playlist how to compile and run the code: code-vault.net/lesson/18ec1942c2da46840693efe9b51d86a8
All of the code I am presenting here is ran under Linux by the way
Great 💣💯
Understood
PERFECTOO