Operating Systems Lecture 14: Condition variables

[mythilivutukuru]

Note a minor error in the video. Lecture 14, On slide 6, the text "Child runs, sets done to 0" should be corrected to "Child runs, sets done to 1".

[Vivek.Rathi.]

Best explanation one can expect. Every line of code is explained logically. Thank you very much.

[venkateshnaresh]

Excellent explanation on the use of conditional variables

[kanhaglobal]

Very Good explanation of CV with p_thread code. Thanks !

[veereshsajjan]

Hi Mythili,


You have done a great job.
Such an easy method of teaching !!

[rishitasantra]

Awesome lecture!Keep adding more videos.Would like to get more informational videos on data structures .

[mocorner]

Shouldn't the mutex lie inside the Sleep check section ? It seems if producer takes the mutex and goes to sleep, the consumer will never get the mutex and be able to create free buffer.
Very helpful video series. Thanks a lot.

[helloworldsk]

Really good explanation indeed. Thank you for sharing the material ma'am! :)

[r.pandey]

Thanks for awesome lecture. And providing clear concept

[coconutjuice]

Thank you!!! This video was really helpful.

[rahulagrawal]

Hi Mythili,
I see no body pointed out here. The slide "Why lock when calling wait" need and update. Chile runs. sets done to 1*
And this lecture is awesome. Kudos to you.

[jacksonnkosinathi]

If I found your videos months ago I will be a dean of school by now, but I found them just hours before my finals😪

[borg]

I have my reservation on the producer/consumer explanation. A better and more efficient implementation would be to use another construct of Pthread library, which is Message Queue. Producer will use mq_send() and blocked on the call until there is a free space on the message queue. Consumer will use mq_receive() and blocked on the call until there is a data on the message queue to consume.

[allonyannay]

It took me time to see that the cond_wait function also gets the mutex as argument and that it releases the mutex so that the child can take it and call cond_signal. Otherwise there would be a dead-lock: Parent holding the mutex and waiting for signal; Child waiting for the mutex and never sending the signal. However this does is not an esthetic solution in my opinion. The semantics of the mutex becomes complex and dependent on a different function.

[akysaxena]

Really very well explained! saved my time reading ostep :)

[saileshsriram]

Really good lecture! Helped me prepare for my upcoming exam.

[rahul]

Hi Madam, very clearly understood thanks.

[srinivaspokala]

I have a doubt in the producer and consumer problem using mutex & conditional variables, where we used "for" loop for both producer n consumer threads to iterate as loops times. Why can't we use infinite loop in both threads in place of loops value in for loop.

[kailashprasad]

When you decide to sleep you must sleep.

[uub]

Isn’t there a dead lock in the guest code with parent and child? What if the parent code runs before the child? It locks and waits for signal. But then child starts and tries to lock… then it can’t lock because parent has the lock, so it wait as well… parent and child are both sleeping, causing deadlock. Am I missing something?