Your tutorials are a goldmine. I took an Operating Systems class that literally had 0 lectures to explain the concept of multithread --- instead just a word vomit of text --- and this video was worth 10x of those classes. Keep up the great work!
These videos have saved me a lot. My university lectures are so convoluted and over the top it takes me hours to understand what they are trying to explain, yet these videos explain the exact same material in a very clear and concise way. Great job and thank you for these videos on C.
in addition to the excellent explanations of multithreading concepts and examples of how they can be useful in application, i really appreciate how you demonstrate the process of problem solving in every episode, starting from programming the most basic model of the program and debugging it as you add more functionality - it really helps to have that good practice demonstrated for beginners like me. also appreciate how often you look into the camera, it really does make the lesson feel more engaging. thank you so much to you and your team, I'll be referencing your content and supporting your channel for years!
wow. jesus. I've sat through hours of class about this subject and never understood a single sentence, but you just explained 5-6 lectures in 25 minutes like fucking Picasso, I've never felt so confident about understanding Producer Consumer multithreading. Thank you!
These are the best Unix C - Threads/Processes video tutorials ever! As a teacher, I recommend and share your videos with all my students. I recommend you to make video series about sockets and network programming with C. Greetings from Bulgaria!
Thank you so much! I'm glad other teachers appreciate my work. And thanks for the recommendation, it is the most requested so far, I'll look into it as soon as possible
Dude you are a champion, such complex concepts you explained so easily. Your videos are so good, keep posting and continue throwing light in to so many peoples careers
this video is absolutely fantastic. I really like your detailed style. explaining everything. I hope that you're doing well, and that you plan to continue in the future.
I understood both the mutexes and semaphores and I now know how to do my homework. Thank you very much. Very clear explanation. Now I am eager to learn more.
Thank you so much! I have to do a kind of program about producer and consumer for the university, and this video helped me a lot to understand the problem!
If you have a producer-consumer-problem and use mutexes, you'd use condition variables along with them. That's much more efficient under load conditions where the producers and consumers are constantly processing.
This video really makes it clear why they are called semaphors. It was a fun video to watch, the 25 minutes of the video flied by so fast. Your videos and Jacob Sorber's videos explain semaphors nicely.
Thanks a lot! On the source code from the description, the if statement inside the loop is different from the one on the video. if (i > 0) instead of if (i % 2 == 0 )
@@CodeVault oh ok that makes sense. But if we want to split the threads between producer and consumer evenly we should keep the mod right? Thanks for all the content by the way, great stuff!
i hate seeing someone like you, who is such an amazing explainer, getting views like that , for this videos therre is only 1_000 views !!! also, i hope you doing some machine learning and ANN stuff on youtube in the futur too good luck
Hi CodeVault, thank you for your great explanation. I want to check if my understanding is correct. First, sem_wait(), sem_post() have to be atomic (not be interrupted). Because of that, their check need to be very trivial. I.e, wait() and post() should only check if( empty/full >0 ). This concept is called guarded commands. Now, because these checks have to be simple, we need two semaphore variables for producer and consumer. I.e, for producer, check if empty > 0 and for consumer, check if full > 0. That is the reason why we need two semaphore variables instead of just "int count"; Am I right?
Why is it a problem? Just use a ring buffer with a read pointer and a write pointer. If the read ptr is the same as the write ptr, the buffer is empty. The write pointer advances the write ptr after the data is stored at that memory location. You will probably need a fence there, to ensure that the pointer is incremented after the data store. The read pointer never increments past the write ptr.
It's a common problem taught by many professors across the globe. You can always argue about its usefulness in the real world but that's not my goal here with those videos. Students are taught poorly about this topic and I'm trying to provide better material for them to learn from I might make a video implementing the improvements you listed there
@@CodeVault oh, cool beans. I had a microcontroller with a cortex-m4 paired up with a m0+ coprocessor. I think it was an NXP LPC 43xx or something. They had a piece of hardware that managed a communication channel between the two cores that worked like I describe. It's kinda like a plan9 channel. Sadly... I don't know if it could be extended beyond two communicating threads...
Thank you for clear explanation. As I understand you use both mutex and semaphores because the usage of two different semaphores does not prevent producer and consumer from executing critical section simultaneously. So you need mutex as well. Is my conclusion correct?
Yes. Without a mutex, you could produce multiple items at the same time, have the critical section executed by 2 consumers at the same time which creates a race condition on the array it's reading from
Great content! 1 follow up question - Let us assume we have 8 threads, 7 consumers, 1 producer. All 7 consumers will wait on sem_wait(semFull). When the producer produces a number, the waits will be released all at once (This is an assumption I am making on how sem_post works) and then the 7 will try to enter critical section and 1 by 1 try to read but after the first consumer has read the data, it will not find any more data to read. How is this handled?
If sem_wait knows to release all the waits 1 at a time for each sem_post, this problem will probably be solved, right? And given that your code does work, I guess that is how sem_wait might work.
Both sem_wait and sem_post are atomic operations. Semaphores have that integer that it keeps track of for threads to know when they should continue execution and when they should not. Well, that process of checking that integer and decrementing it, is atomic. This means that if one sem_wait checked and decreased the value another sem_wait will ALWAYS see the decreased value thus maybe not continuing execution (suppose we have started with a value of 1) I suggest you even make the experiment yourself
Felicitari din nou pentru continut. Sunt developer de 4 ani si am simtit nevoia sa imi reamintesc anumite concepte. Pot spune ca in cateva ore sunt la fel de "fresh" ca in facultate.
So can we say mutex's main purpose for producer/consumer environment is to lock the critical section and semaphore's main function is to provide synchronisation between the threads?
Yes. Basically semaphores are just there so that you can notify threads to wake up when something happened and mutexes for what you mentioned: locking the critical section
sem_wait is using a spin lock (busy waiting) on Linux. But the scheduler might change it to a lock if the spin-lock is not unlocked in a reasonable time-frame
This is incredible👌👏 Just one quick question . Instead of using two semaphores, can we use one condition variable to wait and signal producer and consumer with some conditions?
No. Because you cannot make a thread wait on an arbitrary value of a semaphore (you need to wait for both producer and consumer threads in different situations)
This is an amazing video! Thank you so much! I just have one question, say we wanted a certain produce a certain amount of integers, say 100. How would that be implemented?
Thank you for this great video! I just have a question about how you'd organize the ownership of these mutexes and semaphores in a larger project: Suppose you wanted to use encapsulation as much as possible and avoid creating things in the global scope, as you have done in the video. Maybe you have a producer struct that stores all the properties of one or more producers, and the same thing for the consumer(s). Who should own the mutexes and semaphores? Do you make a separate struct, maybe in it's own translation unit, that contains the mutexes and semaphores that are going to be used for each part of your project? And then the producer struct just stores a reference for each of the mutexes and semaphores it needs? I'm basically just asking: how do you organize it? Thanks!
Hmm... that's a good question. If I had to do it the OOP way I would simply have a main struct that contains information about the consumers, producers and all the synchronization variables (semaphores, mutexes etc.)
@@CodeVault okay, thanks! If you get the chance, I just want to suggest that I'd be interested in seeing a video that talks about how you'd commonly see (medium to large) c projects structured in the wild, and maybe some common design patterns that are typically used. If you've already done that, sorry! I'm still making my way through your videos.
9:56, Frankly I would not share control of the buffer variables, instead I would make the consumer thread treat them as read only, something like: #define PRODUCE 10 bool producing = true; uint consuming = false; uint count = 0; int buffer[PRODUCE] = {0}; void* producer( void *ud ) { while ( producing ) { for ( count = consuming; count < PRODUCE; ++count ) buffer[count] = rand() % 100; while ( consuming ) pthread_yield(); consuming = count; } return NULL; } void* consumer( void *ud ) { while ( producing ) { consume: while ( consuming ) printf( "Got %d ", buffer[--consuming] ); } if ( consuming ) goto consume; return NULL; } **Edit:** Thought of a different method I liked better so I modified the above to reflect
If we are using mutex in consumers and let's say there are multiple consumers who wants to work parallelly wouldn't that affect the parallelism of the program?
@@ShivamGupta-gn8cn Well, usually you will need to synchronize threads for certain operations. For adding and removing from the tasks list we really have to have a mutex around it. Although, you should consider that the operation of adding or removing from the tasks list is much MUCH less performance intensive than executing the tasks themselves.
Great video! Really enjoyed it. I have a question though. If I have multiple producercers , will this code cover that case as well. If not, could you suggest what other modifications are needed. Thank you.
@@CodeVault It only consumes the last produced element. Shouldn't it produce all N elements, then they get consumed one by one and finally produce N elements again?
Great video , is there way thr consumer can add to the buffer with minimum waiting while the slow consumer is busy consuming. Thanks. Thst Is When there still slots on the buffer. Thanks.
I'm not sure what you mean by "minimum waiting" but simply executing what the producer is doing inside the consumer's function should do the trick. Just be careful to not create an infinite loop since then your consumer would also be a producer
@@CodeVault Thanks for the insight. My producer can very rapidly insert new packets to a fixed size circular buffer/array[4], but my consumer is very slow. Producer should only wait if already full of new packets, and consumer can wait if no packets. But producer shouldn't be blocked while trying to insert a new packet when not full. I was worried the slow consumer taking the mutex could prevent the producer to take the mutex to insert a packet to non-full circular buffer. The slowness of the consumer shouldn't affect the producer from adding new packets while not-full. Appreciate any suggestions, thanks, and merry Christmas.
The mutexes on both sides are important as to not cause race conditions. I think you have to think a bit differently about the consumer/producer problem. In the real world, for the vast majority of cases the actual "producing" and "consuming" part of the algorithm is what takes most of the time. The time waiting by locking/unlocking a mutex is insignificant in the grand scheme of things. Now, to improve the performance of inserting/removing from your buffer you could implement it using a linked list with 2 mutexes. Then you would only need to lock certain parts of the linked list to insert and remove
One question I tried running the code and it seems like it never ends. How can I give it a limit to work on say like when there is nothing on the buffer to stop or any type of signal to terminate. Video is amazing as usual.
One simple way is to just change the while(1) to some other proper condition. Another way you could do it is have a timer variable and decrement it each second on a separate thread and reset it back to the initial value whenever you have consumed an item. If the timer gets to 0 then the thread simply terminates the whole program (by calling exit() or something)
It's fairly simple, just take the first element and move everything to the left by one index: if (count > 0) { y = buffer[0]; for (int j = 0; j < count - 1; j++) { buffer[j] = buffer[j + 1]; } }
Great video, there are multiple producer/consumer videos here but this is the best and easy to understand to cover multiple/multiple case. Question, which is the better way to implement a producer/consumer? Use semaphores like this or condition variables (like you implemented the gas station)? Because, if pthread_cond_broadcast() is used then multiple consumers case can be covered. Can't it be implemented if pthread_cond_broadcast() is used at both sides to handle multiple/multiple situation?
Yes, you can do it with condition variables as well! And actually it's a good exercise. I don't think you need broadcast even when dealing with the multiple/multiple situation unless your producers create multiple values in the buffer.
@@CodeVault Please re-consider to print out the value at the outside of semaphore protection of consumer() function. I just checked, if consumer has some delay and doesn't go into the semaphore routine then it prints a garbage value.
Thanks for your perfect and beautiful code But why for us didn't print done when the buffer was consumed? In my case i produce n items and when all of them was consumed it shows done So i bounded while for n items Is it true?
Hi ,Sir. its a great platform for me.. Sir can you make lectures on "Semaphore with multi process(fork()) " and on "Semaphore with multi process (shared memory synchronization)"?
Despite 1 year late, I would like to correct things here: 1. Use rotating buffer instead of linear one, it's a lot faster for big array 2. Rotating buffer uses 2 integers, cursor and current length 3. Don't overcomplicate the code as example using "for" loop to initialize only 2 thread. This hurts beginners
basically you should not be a beginner if you're watching this video. You're supposed to have a good knowledge of programming concepts, C language, Data Structures and Alghoritms. So a for loop should now scary you. It makes no sense to start learning multi-threading programming if you don't have the basics.
Is this what you mean?: Why when we add sleep(1) to both the consumer and producer threads it doesn't wait 2 seconds? It's because both threads run in parallel so both start waiting 1 second and stop waiting for 1 second at the same time
With multi-threaded applications not everything is the same on every machine at every time. I think I also had to run it a couple to get this result. That's kind of the difficulty in creating multi-threaded applications, these types of situations are not guaranteed everywhere but they CAN happen
@@CodeVault I see what you mean. I was coding along to I was double checking I had the equivalent thing and by the end I was comfortable with it. Your videos on mutexs, semaphores and condition vars helped me so much and you made them fun to learn
Hi, let's say I want to make a data logger that is getting data and logging it to a database. What sort of architecture should I be looking at. I think this is something to start with.
If it's on the same project that you're logging, then yes, 1 consumer for saving to the database and the producers are whatever threads you have on your project. Otherwise, if it's a standalone project just for logging, you might want to use sockets and send the data through them. There you don't really need thread synchronization as the database should be taking care of that for you.
