L-3.2: Producer Consumer Problem | Process Synchronization Problem in Operating System

Summary

The video script delves into the producer-consumer problem, a quintessential multi-process synchronization issue. It introduces two parallel processes: the producer, which generates items and places them in a shared buffer, and the consumer, which removes and processes these items. The script meticulously explains the potential race condition that arises when the producer and consumer access the shared buffer without proper synchronization, leading to inconsistencies like the buffer holding more items than the count variable indicates. The discussion emphasizes the importance of synchronization mechanisms like semaphores, monitors, and locks to prevent such issues, hinting at their exploration in future videos.

Takeaways

• 👥 The producer-consumer problem is a classic example of multi-process synchronization where two parallel processes, a producer and a consumer, interact.
• 🔁 Both processes run concurrently and share resources, such as a common buffer and a count variable, which tracks the number of items in the buffer.
• 🛠️ The producer's role is to produce items and place them into the shared buffer, while the consumer's role is to consume these items from the buffer.
• 🔄 The buffer is a circular data structure that allows for efficient use of memory by reusing the same space for new items once older ones are consumed.
• 🔢 The count variable is crucial for synchronization, as it indicates the number of items currently in the buffer, and it is modified by both the producer and the consumer.
• 🔁 The producer increments the count when an item is produced and added to the buffer, while the consumer decrements it when an item is consumed.
• 🔄 The use of the 'mod' operation in the buffer indexing ensures that the buffer wraps around to the beginning once the end is reached, maintaining a continuous cycle.
• 🚫 A potential issue arises when the producer gets preempted after incrementing the count but before the item is actually placed in the buffer, leading to a race condition.
• 🔄 The script illustrates a scenario where the producer and consumer execute their instructions out of order due to preemption, resulting in an incorrect count that does not match the actual number of items in the buffer.
• 🔒 To resolve synchronization issues like race conditions, mechanisms such as binary semaphores, monitors, or locks are necessary to ensure that the producer and consumer access shared resources in a controlled manner.

Q & A

What is the producer-consumer problem?

The producer-consumer problem is a classic problem in multi-process synchronization where two processes, a producer and a consumer, operate in parallel and share resources. The producer generates items and places them in a shared buffer, while the consumer retrieves and processes these items from the buffer.

What is the role of the buffer in the producer-consumer problem?

The buffer in the producer-consumer problem serves as a shared memory space where the producer can place items it produces and from where the consumer can retrieve items for consumption. It acts as an intermediary storage between the producer and consumer processes.

What is the purpose of the 'count' variable in the producer-consumer problem?

The 'count' variable in the producer-consumer problem is a shared global variable that keeps track of the number of items currently in the buffer. It is used to determine whether the buffer is full (for the producer) or empty (for the consumer) and to manage the synchronization between the producer and consumer processes.

How does the producer process know when the buffer is full?

The producer process knows when the buffer is full when the 'count' variable equals the maximum size of the buffer. If the count is equal to the buffer size, it indicates that the buffer cannot accommodate any more items, and the producer process must wait or handle the overflow situation.

What happens if the producer process gets preempted after incrementing the 'count' variable but before storing the new value back to memory?

If the producer process gets preempted after incrementing the 'count' variable but before storing the new value back to memory, it can lead to a race condition where the actual number of items in the buffer does not match the 'count' value. This discrepancy can cause synchronization issues between the producer and consumer processes.

Why is synchronization important in the producer-consumer problem?

Synchronization is crucial in the producer-consumer problem to ensure that the producer does not overwrite items that the consumer has not yet processed and that the consumer does not attempt to read from an empty buffer. Proper synchronization prevents race conditions, ensures data integrity, and maintains the correct order of operations between the producer and consumer processes.

What is a race condition in the context of the producer-consumer problem?

A race condition in the producer-consumer problem occurs when the outcome of the program depends on the non-deterministic or unpredictable order of execution of the producer and consumer processes. This can lead to inconsistent states, such as the 'count' variable not accurately reflecting the number of items in the buffer.

How can the producer-consumer problem be resolved to avoid race conditions?

The producer-consumer problem can be resolved by using synchronization mechanisms such as semaphores, mutexes, monitors, or locks to control access to the shared buffer and the 'count' variable. These mechanisms ensure that only one process can modify the buffer or the 'count' variable at a time, thus preventing race conditions.

What is the significance of the 'in' and 'out' variables in the producer-consumer problem?

The 'in' and 'out' variables in the producer-consumer problem are used to track the positions in the buffer where the next item will be produced (for the producer) and consumed (for the consumer), respectively. These variables help manage the circular nature of the buffer and ensure that the producer and consumer processes access the correct positions in the buffer.

How does the consumer process know when the buffer is empty?

The consumer process knows when the buffer is empty when the 'count' variable is zero. A 'count' value of zero indicates that there are no items in the buffer for the consumer to process.

Outlines

00:00

🤖 Introduction to Producer-Consumer Problem

The paragraph introduces the producer-consumer problem, a classic issue in multi-process synchronization. It explains that there are two parallel processes involved: the producer and the consumer, which share resources such as memory or variables. The producer generates items and places them in a shared buffer, while the consumer retrieves and processes these items. The script presents the consumer and producer codes written in C language and discusses the initial conditions, such as an empty buffer and a shared global variable 'count', which tracks the number of items in the buffer. The producer checks if the buffer is full before placing a new item, and if so, it enters an infinite loop, illustrating a potential deadlock situation.

05:05

🔁 Buffer Operations and Count Variable

This section delves into the mechanics of how items are produced and consumed using the buffer and the 'count' variable. It describes how the producer increments the 'in' index to place a new item in the buffer and how the consumer uses the 'out' index to consume an item. The 'count' variable is crucial as it indicates the number of items currently in the buffer. The paragraph also explains the use of the modulo operation to handle buffer indexing, allowing the indices to wrap around the buffer size, ensuring a circular buffer behavior. The CPU's role in executing the increment and decrement of the 'count' variable through micro-instructions is also highlighted.

10:06

🔄 Consumer Process and Buffer Interaction

The focus shifts to the consumer process, which checks if the buffer is empty by examining the 'count' variable. If the buffer is empty, the consumer enters an infinite loop, waiting for items to be produced. The script then describes a scenario where the consumer consumes an item, updates the 'out' index, and decrements the 'count' variable. The importance of synchronizing the producer and consumer processes is emphasized to prevent race conditions. The paragraph also discusses the potential issues that arise if the producer and consumer access the buffer and 'count' variable without proper synchronization.

15:09

🔄 Advanced Buffer Management and Process Preemption

This paragraph explores a more complex scenario where the producer has already produced multiple items, and the consumer has not yet consumed any. It discusses how the producer places a new item into the buffer and updates the 'in' index and 'count' variable. However, the producer process gets preempted before it can complete the update of the 'count' variable. The consumer then runs, consumes an item, and incorrectly updates the 'count' variable due to the preemption, leading to a race condition where the 'count' variable does not accurately reflect the number of items in the buffer.

20:09

🔄 Process Synchronization and Race Conditions

The final paragraph emphasizes the importance of process synchronization to avoid race conditions. It outlines a scenario where the producer and consumer processes are not synchronized, leading to incorrect values of the 'count' variable. The paragraph describes how the producer and consumer processes interact and how their instructions are executed, leading to a situation where the 'count' variable does not match the actual number of items in the buffer. It concludes by suggesting the use of synchronization mechanisms such as binary semaphores, monitors, and locks to resolve these issues, which will be covered in future videos.

25:13

📚 Conclusion and Future Learnings

The concluding paragraph summarizes the discussion on the producer-consumer problem and the importance of process synchronization. It highlights the potential issues that can arise if synchronization is not properly implemented, such as race conditions and incorrect buffer counts. The script encourages viewers to review the video if they have any doubts and looks forward to exploring solutions like binary semaphores, monitors, and locks in upcoming videos.

Keywords

💡Producer Consumer Problem

The Producer Consumer Problem is a classic example in computer science that illustrates the need for synchronization between multiple processes. In the context of the video, it refers to a scenario where two parallel processes, a producer and a consumer, interact with a shared buffer. The producer generates items and places them into the buffer, while the consumer takes items from the buffer for processing. The video script discusses how synchronization is crucial to prevent issues such as buffer overflow or underflow, and race conditions.

💡Multi-process Synchronization

Multi-process synchronization is a concept that ensures that multiple processes in a system operate in a coordinated manner. In the video, synchronization is necessary to manage the interaction between the producer and consumer processes to avoid conflicts over the shared buffer. Proper synchronization prevents the producer from overwriting the buffer when it's full and ensures the consumer doesn't try to read from an empty buffer.

💡Cooperative Processes

Cooperative processes are those that work together to achieve a common goal, often by sharing resources such as memory, variables, or other data. In the video, the producer and consumer are cooperative processes because they share a common buffer. The script explains that these processes must coordinate their actions to ensure that they do not interfere with each other's operations.

💡Buffer

A buffer in the context of the video is a shared memory space where the producer places items for the consumer to process. It serves as an intermediary storage that allows the producer to continue producing items without waiting for the consumer to finish processing. The script uses the buffer as a central element in the producer-consumer interaction, highlighting how synchronization mechanisms are needed to manage access to this shared resource.

💡Global Variable

A global variable is a variable that is accessible by all parts of a program. In the video script, the 'count' variable is a global variable shared between the producer and consumer processes. It keeps track of the number of items currently in the buffer, which is crucial for synchronization. The script explains how changes to this variable must be carefully managed to prevent race conditions.

💡Race Condition

A race condition occurs when the behavior of a system depends on the non-deterministic arrival of events or messages, leading to unpredictable or erroneous results. In the video, a race condition is exemplified by the scenario where the producer and consumer processes interfere with each other's operations due to unsynchronized access to the shared buffer and count variable, leading to incorrect counts and potential data corruption.

💡Semaphore

A semaphore is a synchronization mechanism used to control access to shared resources by multiple processes. Although not explicitly detailed in the script, the video mentions that semaphores can be used to solve the race condition problem in the producer-consumer scenario. Semaphores can be used to ensure that only one process accesses the buffer at a time, thus preventing conflicts.

💡Modulo Operation

The modulo operation is used in the video to manage the circular nature of the buffer. When the producer or consumer reaches the end of the buffer, the modulo operation (e.g., 'in = (in + 1) mod n') wraps the index back to the beginning of the buffer, allowing for continuous production and consumption of items without exceeding the buffer's bounds. This operation is crucial for implementing a circular buffer in the producer-consumer problem.

💡Pre-emption

Pre-emption in the context of the video refers to the interruption of a process's execution by the operating system, allowing another process to run. The script describes a scenario where the producer process is pre-empted after incrementing the count in memory but before the change is fully reflected, leading to a synchronization issue. Pre-emption is a common occurrence in multitasking systems and must be accounted for in the design of synchronization mechanisms.

💡Process Control Block (PCB)

A Process Control Block is a data structure used by the operating system to store information about a process. In the video, the PCB is mentioned as a way to keep track of the progress of the producer and consumer processes. When a process is pre-empted, the state of its execution, including the values of variables and the point of execution, is saved in the PCB. This allows the process to resume from where it left off, which is essential for maintaining correct synchronization in the producer-consumer problem.

Highlights

Producer-consumer problem is a classic example of multi-process synchronization.

The producer and consumer processes run in parallel and share resources.

The producer places items into a shared buffer, while the consumer removes them.

The count variable is used to track the number of items in the buffer.

The buffer is a shared memory space between the producer and consumer.

The producer checks if the buffer is full before producing a new item.

If the buffer is full, the producer process can get stuck in an infinite loop.

The consumer checks if the buffer is empty before attempting to consume an item.

The consumer process can also get stuck in an infinite loop if the buffer is empty.

The producer increments the count after placing an item in the buffer.

The consumer decrements the count after removing an item from the buffer.

Race conditions can occur if the producer and consumer access the buffer without proper synchronization.

The problem of incorrect count values due to process preemption is highlighted.

Process synchronization is crucial to prevent data inconsistency in the buffer.

Binary semaphores, monitors, and locks are mentioned as potential solutions for synchronization.

The importance of testing software under various scenarios to ensure proper synchronization is emphasized.

The video provides a detailed walkthrough of the producer-consumer problem, including potential issues and solutions.

Transcripts

Producer consumer problem...

Producer consumer problem is a standard problem of multi process synchronization

Means we've two processes here, one is of producer and one is of consumer

And the assumption is both processes are coming at a same time,

means both are parallel processes And they're sharing something

Means we are talking about cooperative processes,

In cooperative processes, two or more processes... They share something,

it could be code or resources, or memory or some variable also

Something common between them, so we are talking about the cooperative processes only

So one is producer and other one is consumer

This is the code for the consumer and this is the code for the producer

It's just a code written in normal C language

Let's see producer, when producer's code runs then producer produces an Item

And places it in a buffer

And what consumer do is, it consumes the item and to consume it'll execute this whole code

And then finally will bring out the item from the buffer

And then it can process anything it wants

This is the way of how we are doing this

So let's start with the case 1, we are starting with the normal case i.e. best case,

because when we run the program then there could be many cases

I mean when we execute a program in the real world or creates some situation in the real world

then we are not bound with only one or two cases

I have to check all cases, so we are taking a simple case

Like Case1... In case one, producer is producing an item

It's just any random item let's say item is X1

Item name is X1

Now... to producer item X1, producer's process will execute this code

So it's simple... Int count = 0 Count is a global variable that both are sharing

We just talked that there's some share or something common in cooperative

Here in producer consumer problem, this is the buffer which is shared by both the processes

Both processes are sharing this buffer

Buffer is like a memory or space in RAM that both processes are sharing

And one more thing they are sharing is the count variable

Now void producer (void).... Int item p this is the local variable of producer

While (true), which is always true

produce item (item p)... this is a function which will produce an item

So let's say Item P... while (count == n)

n is the size of the buffer I've already picked up n's size as 8

Means the size of buffer is 8 And index is zero to n-1

Means from zero to 8-1 i.e. 7

so already there's numbering, 0,1, 2, 3,... 5, 6 ,7

And we are doing increment and decrement by using two local variables

Consumer uses out,

And producer uses In

Now let's say that producer produced an item while (count == n)

What is the meaning of this condition if the count is ==n

Means if the size of count is equal to size of the buffer, it means that the buffer has over flown

If buffer is overflowing, means I can't produce any other item in it

So if I can't do it, then there's a semicolon there

Means this code will stop here definitely Means this producer will get stuck in infinite loop

obviously if my buffer is filled from 0 to 8 completely

Now if counts value is equal to the maximum size of buffer

This is the condition for buffer full Buffer is full

obviously if the buffer is overflow then we can't produce any item

even if I created an item then where will I save it?

Then I have to put it in the buffer but buffer is already full

then here producer will get stuck in infinite loop

But we are taking the normal case where let's say my buffer is initially empty

and producer came and want to produce a new item

So now let's jump to the next line... Item p Buffer [in]

Means whatever the item... Let's say Item is X1 Buffer [in]... by default in

Starting position of in is 0 in tell the address of next empty slot

Means it tell the addresses of empty slot where that item will reside inside the buffer

So now my item is pointing out at int 0 position Means 0th position is empty

Means we are incrementing like this

When item will keep coming then we'll keep incrementing in

And when we'll release item then we'll increment out

Let's say Item P i.e. X1... and buffer in what is the position of in?... Zero

So we filled item X1 in the buffer

we filled item X1 in the buffer in =( in+1) mod n

What is the value of in?... Zero then (0+1) mod 8

n is the maximum size of the buffer i.e. 8 so this 1 mod 8

and we already know this is the reminder 1 mod 8 is equal to 1...

means now in will become increment to 1

so this is a simple case that how we produced an item and placed it in the buffer

now the last condition is count = count +1

Now count variable which is used by both producer and consumer

So I have to increment count variable also

count variable which is initially zero Count says that how many items are there in the buffer

for now there's no item so it's a zero But we added a new item i.e. X1

so count will also change from zero to 1

so this is how the code will execute

now if you see this part

Count = count +1 this is an important part over there

count is a simple instruction This is a simple instruction of C, count = count + 1

but how CPU executes it... this is very important

CPU converts every instruction into micro instruction and then executes it

so how this instruction will convert into micro instruction?

first we'll load count's value from the memory in a register... Let's say register is Rp

Because CPU works on registers first for efficiency and time saving

so what I did? count's value was Zero initially

So I loaded zero in the register

Then increment... INCR is increment Increment of Rp

so Rp's value will change from zero to 1 in the register

and then we store the value of Rp into m [count]

so M [count] will change from 0 to 1

Same..

Let's say how the consumer works

Now whenever consumer wants to consume an item

then it'll confirm from the same buffer Means it'll use the same buffer

means both are sharing the common buffer over there

now they are sharing the common buffer then let's say consumer came and chose item C

This is the while (true) which is always true while (count ==0)

What is the meaning of while (count ==0)? It means if count's value is equal to zero...

count tells how many items are there in the buffer

and if there's no item in the buffer Means my buffer is totally empty

so obviously this will be an infinite loop means consumer don't have anything to consume

so it'll get stuck here in the infinite loop so what this condition is telling us?... Buffer empty

that the buffer is empty... if buffer is empty then there's nothing to consume from the buffer

so consumer's code will stuck in infinite loop

so let's say that there's something always to consume so Item C... Buffer (out)

Now out is what?... out is by default again it's starting from the zero

Means how we are running the items when putting the item then we are putting from 0 to 7

and when we are bringing out items then we'll keep incrementing to next position from 0

and now we are using mod then what is the advantages of mod??

it'll move from 7th position back to 0th position

Let's say buffer out... what is buffer out, out value is initially 0,

because we're always putting out item at 0th position

We are entering item at 0th position and taking out at 0th position also

So let's say buffer out... what is the position of buffer out?... Zero

so whatever value is there in the 0th position, it'll come in the item C

what's the value in this?... X1

There's an item X1 which is primarily produced by producer

so X1 item will come under item C,

now when X1 item will come in item C, then we have to update out

because out will show at the next value

because consumer have already consumed it, so we'll increment out from zero to one

so that consumer have to consume a new item

so it's fine it can consume item from 1 position also

In any case, it maybe possible that my buffer is filled,

then consumer can pick multiple items also one by one

We changed out's value from 0 to 1

now it'll point on 1, if there'll some item then it'll consume from there

then it'll keep moving next, this is the way so out = (out +1) mod n

so out's value in starting is 0, so (0+1) mod n

What is mod n?... n value's 8 so 1 mod 8... i.e. . So out value will be out

so I updated out's value from 0 to 1

now this is again important because count is common in both

Count variable is common in both that's why this is the most important instruction

Count = count - 1 Count -1 means...

we consumed an item, then obviously we have to reduce count's value by 1

so count = count - 1 this is also a normal instruction

We've written a line in C count = count -1

But How does CPU executes it?... again through micro instructions

Let's say what it'll do first? count value from memory...

What is the count value now?... count value is 1

because there was just one value in buffer We entered that one value, so count value is one

so 1 will be loading into the register let's say there's a dedicated register for consumer

so value 1 will get load in that consumer's register

Decrement of Rc... means we decremented value from 1 to 0

and then zero will be loaded into n count

means we again changed count's value from 1 o 0, means stored value from 1 to 0

So it means count's value now is also zero

so count's value zero means that we consumed the item from here

so there's no item which is left over there

obviously there's no item, we saw a simple case, first we produced an item, then placed it in buffer

then consumer consumed the item took out of the buffer

then count changed again from 0 to 1, and then from 1 to 0

we took out the X1 that we produced

now out will point on next one that it wants to read

and if there's next item then it'll use it

In is also there... if I want to produce some item then we'll produce it here

this way we'll keep incrementing when we'll go from 7 to 8

then 8 mod 8... again 0 then again my pointer will move after 7 to 0

This is a normal case, which we generally call best case

that if my code will work in a way that producer came first,

then consumer came, then producer came and again consumer

then there's no problem

this will be perfectly fine, but now we are moving towards the next

Next case is...

Let's say... now we are talking about process synchronization

in process synchronization if these processes aren't synchronized

Let's say... at any point of time producer produced three items

Let's say X1... X2, ... X3

These three items at any point of time, anytime.. this can happen this is one of the case

these three items have been produced so in count it's showing 3

Because there's three items so value in count is 3

In... what In will show here? Always the next empty slot

As we discussed... Next empty slot

because we always keep In's value one extra incremented

so that we can keep getting next value where I have to place the item

and out.... Let's say, that consumer haven't consumed any item until now

so we are starting from zero

Now let's run this program again,

let's say producer is ready to produce one more item

Producer has already produced three items and now wants to produce a new item

so we are running this code again

Let's say producer produced an item while count is == 1

While (count ==n) Count value is 3

3==n? NO... false, because still we have empty slots

so we'll easily jump from here to next

Means we came out of the loop

Buffer... Let's say the item is X4

In this case, Let's say the item is X4

So we'll do In X4... What is the In position?... 4

4 position is what??...

This is 3... because next empty position is three

So let's say, we'll insert the item in third position

This is the third position... So X4, we inserted X4 here

This statement says X4 will be inserted into buffer in

What is the In value?... 3

So in buffer IN, we inserted an item X4 in 3 value at 3rd place

In = In + 1... Again we incremented In Because In always tells the next empty slot

so that producer can produce next empty slot there

Now let's say count = count + 1 Because we have to increment count

Because now here 4 items came but count is at 3

so obviously we've to update count so my whole producer's code will terminate

But let's say count = count + 1

This one... load Rp, m [ count ] What's the count value now?

Count value is three... Previously count value is 3

Three value will be loaded into the Rp

Let's say there's one register Rp in which we loaded value 3

Now, Increment of Rp... Next section is increment of Rp

Means we incremented Rp form 3-4 When incremented from 3 to 4...

Let's say third instruction is store Rp into m [ load ]

But now we are taking one case that after this 2nd instruction this producer got pre-empted

Means this process has got pre-empted because whenever we run processes in real time

Then process can get pre-empt anytime, reason could be... Interrupt

Maybe some hardware of software got interrupt or some high priority process arrived

or time quantum... that maybe its time quantum got expired

In any case, process can get pre-empt anytime

So let's say it executed 1 & 2 instruction it executed this 1st & 2nd one

entered the value of m [count] i,e, 3 in the Rp Did increment of Rp, it became from 3 to 4

Internal resistor value changed from 3 to 4

But before it would run 3rd instruction, the producer code got pre-empted already

CPU will always search for new processes,

if there's any other process in the ready queue that it can change to running

yes, there's one more process

Now see, consumer came and run this code... while (count==0)

we have already a lot of items to be consumed, so this is false

so it came in, buffer out... what is out value?... Out value is Zero

means we can read something with zero value here...

What is value at 0th position?.... X1

So it'll put X1 in item C... will consume it Out = (out+1 ) mod n

The same....out value is zero 0+1 mod 8 i.e. 1

so we shifted value from zero to one here and item x1 got consumed from here

obviously when it placed item in its local variable then item left the buffer

We did out = out +1 Count = count -1

The next instruction is count = count -1

m [count]... same What is the m [count] over there

m [ count] is 3... count value is 3

it entered count value 3 in the register Let's take a register here... Rc

In Rc register we entered value i.e. 3,

count's value is 3 because it didn't get updated until now and system already got pre-empted

so my count value here came 3... decrement of Rc i.e. 2

It got decremented... but same Before I would execute third instruction,

system got pre-empted already before it

let me write here for your easiness... Case: In this case what we are doing

First of all producer came... producer is executing the instruction I & II

This instruction I & II

But before it would execute instruction III, consumer already arrived

This is how we are doing it first producer came, executed item 1 and instruction 2

after that, consumer arrived consumer executed instruction 1 and instruction 2

This is instruction I & II...

but before it would execute III, it got pre-empted and producer came again

When producer came again, then it has already executed up to here

So this value will be same in the PCB that we have the process executed up to here

So we'll resume it, we'll never restart it otherwise our CPU's efficiency will get so much reduced

So PCB will indicate that we've done up to here Only third instruction was left

So we executed third information that's i3

The moment we executed i3, what is the value of Rp?... 4

Value of Rp is 4 in the local register So we loaded 4 value in the count

Now the count is updated with 4

Count is updated with 4 means third instruction got executed

Code got terminated because this process has ended

So when it got over then it got terminated

when it got terminated then the consumer will get the control back

so in consumer also we'll check in PCB, all these values were executed already

In count also, this one and two was already done Just third one was left

So which is the third one again?... consumer's i3

This is the flow...

which will help you how to execute this

So consumer came and run the last instruction i.e. i3 The moment it ran i3

What is Rc... In Rc the value in register is 2 We'll load 2 value... memory count

Memory location of count... What is memory location of count?... This

So we again updated the value from 4 to 2 Now the value of count is 2

What is the meaning of that?

here this statement got executed, means this code is also executed,

when this code got executed then this also got terminate

so when both process got terminated... Now value of count is 2

So it means I have 2 items in the buffer But just check the buffer...

How many items are there in the buffer 1... 2.... 3

there are 3 items in the buffer But the count is wrong over there

And obviously it should be 3...

we had 3 items, out of them, 1 we produced and then consumed one

so it became 4 and should be 3 back again but here count says that there are 2 values only

But there are 3...

So there are 3 values in buffer and count says 2, so this is the problem

This is again race condition problem We checked it out in the last video also

This is again called the race condition where wrong values are competing

if we ran producer here first,

if you'll run consumer first then producer then there must be something else value

But three value won't arrive so this is the case because of which

we failed to achieve process synchronization so here we are getting wrong value

So you just focus on producer, then i1, i2 of producer then consumer i1, i2 of consumer

then again producer... just make a note of that

If you have any doubt in middle then you can revive the video and play it again

This is the flow that how we deal with the producer- consumer problem

Now some of the viewers might be thinking that why this case has been made

Because I said already that when we bring a situation in real world

even if we brings a software in the market, so when we do its testing

then we don't see 3-4 cases in testing

we tries to get maximum situations to test the case, that's the best

so there could be a lot of cases to execute this

but does processes are getting synchronize in all cases?... NO

So there's one case if we'll execute it like this in this way... here problem will create

So this is the problem count is telling 2, but right one is 3

so this is again the problem, if the process synchronization is not done then this problem can arise

now we can remove it again using the binary semaphore, using monitors,

using locks and other methods are there, which we'll see in the future videos

Thank You guys!!