the producer consumer problem can be solved by

How to Solve the Producer-Consumer Problem in Java using Multithreading

Concurrency is an important part of Java applications. Each application has multiple processes running at the same time. This helps utilize resources efficiently and improve performance.

Multithreading is a method of achieving concurrency. It uses the concept of threads – lightweight processes – to execute multiple tasks in parallel. A very popular application of multithreading is the producer-consumer problem.

In this tutorial, we are going to understand what the producer-consumer problem is and touch upon threads and multithreading briefly. Then, we are going to understand how to solve the producer-consumer problem in Java using threads.

Now, I assume you have a basic knowledge of Java. If not, then check out the following resources.

• Free Java Courses for Beginners
• Basics of Java Programming

Table of Contents

What is the producer-consumer problem.

• Solution using Producer and Consumer Threads and Issue with Synchronization
• Introducing Synchronization in the Message Queue Class

Producer with Multiple Consumers

Solution using java concurrency's blockingqueue class.

The producer-consumer problem is a synchronization problem between different processes. There are three entities in this problem: a producer, a consumer, and a memory buffer. Both the producer and consumer share the same memory buffer.

The producer produces some items and pushes them into the memory buffer. A consumer then consumes these items by popping them out of the buffer. If the buffer is empty, then the consumer waits for the producer to push an item, which it consumes after the producer pushes it.

The memory buffer is of fixed size. If it is full, the producer waits for the consumer to consume an item before pushing a new one. The producer and consumer cannot access the buffer at the same time – that is, it's mutually exclusive. Each process should wait for the other to finish its work on the buffer before it can access the buffer.

Operating systems often encounter this problem where multiple processes access the same memory space to perform their tasks.

We will solve this problem using multithreading, so I assume you have a basic idea about what multithreading is and how it works. If not, then you can read through this tutorial .

We'll start with an attempt to solve it simply using threads and a separate class for message queue. Then, we'll understand its issues and how to overcome them in the next approach. We'll also see other approaches to the problem. Make sure to stick around until the end.

Solution using Producer and Consumer Threads

Let's go over our requirements first.

• Producer and Consumer tasks run in separate threads
• Common data bus, typically a message queue, used by both producer and consumer.
• If not full, producer pushes data into queue, or waits for it to be consumed
• If not empty, consumer takes data out of the queue, or waits for producer to publish.

These are the things we need to implement to solve this problem. Let's create the message queue first.

Message Queue

To set up a message queue, we'll use a class that contains the queue and methods to publish and consume messages.

Here, we have used Java's Queue class to store our messages. Each message is of type String . But in bigger applications, the message or payload could be of any object type. We also define the capacity of the message queue.

Next, we'll implement the publish() method. The method accepts a new message to be published.

First, we check if the queue is full. We can't publish a new message if the queue has reached capacity.

If the queue is not full, then add the message to the queue.

We'll add print statements to understand the workflow better.

Here, we just print the thread that is inside the method, the message published, and the resulting queue.

Let's implement the consume() method now. This method does not take any arguments and works similarly to the publish() method. We first check if the queue is empty, before removing anything from the queue.

Then, we remove the message.

Again, we'll add print statements to understand the workflow better.

Producer Thread

Let's write the producer logic now. We'll create a class Producer that will run in a thread. There are several ways to create threads in Java. We'll use the Runnable interface to create our thread since it's the most preferred approach.

The producer has access to the data bus object which is passed to it via the constructor. The producer logic goes inside the run() method. By overriding the run method, you are writing functionality that runs in a thread.

Now, a producer's ways of producing and publishing data differs in every application. For this post, we are going to simulate a functionality where the producer keeps publishing messages every few seconds.

We'll define a list of messages that the producer can use.

Here's the producer logic inside the run() method:

In this code, the producer is publishing a message from the messages list every 1000 ms. Thread.sleep( some_delay ) pauses execution of the thread for a certain period. Since it throws an exception, we surround the code with a try-catch block.

This is just for demonstration purposes – don't worry about the logic. Our implementation works regardless of the producer or consumer logic.

Consumer Thread

Similar to producer thread, let's simulate the consumer logic.

Here, the consumer tries to consume a message every 2000 ms.

Putting it all Together

Now, we have our message queue along with the producer and consumer classes. Let's create one producer and one consumer thread and start them.

We'll create a Data object with capacity of 5 messages and create our producer and consumer threads with the objects of the Producer and Consumer classes.

The run() method executes in a separate thread when start() is called.

Here, the output is inconsistent with the desired workflow. Even after publishing the first message, the consumer is still waiting. Then, a consumer has consumed a message Hi!! that doesn't exist. The state of the queue is also inconsistent.

You will probably get a different output, since thread execution depends on the core OS. But the issue still persists. Why does this happen?

Synchronization Issue With the Data Class

Both producer and consumer threads run simultaneously, working on the same resource. They are accessing the message queue at the exact same time. Both the threads may start with one version of the resource and by the time they perform an operation, they are working on a different version.

This leads to a race condition. Both threads end up competing for the same resource and give inconsistent results. The producer thread is trying to add a message to the queue, while at the same time a consumer is trying to consume a message. There's no way of controlling which message the consumer could get.

To solve this issue, we need some kind of mechanism to ensure that only one thread can operate on a shared resource at a time. In this case, we'll use the concept of synchronization .

At a glance, a synchronized function or a block can only be executed by one thread at a time. A thread entering such a block acquires a "lock" on the object and any other threads have to wait until the thread releases this lock – that is, until it finishes working on the shared resource.

We'll use a similar method to solve our issue.

Introducing Synchronization in the Message Queue

To ensure the message queue is only accessed by one thread (producer or consumer) at a time, a thread needs to secure a lock on the Data object before performing any operations.

How to Use the synchronized Keyword

An object can be made mutually exclusive by using the synchronized keyword. We'll use the synchronized keyword with the publish() and consume() methods.

Now, a thread needs to acquire a lock on the object before entering these methods.

What are the wait() and notify() Methods?

We have achieved synchronization – only one thread can access a shared resource at a time to ensure consistency. Now, we need to establish communication between the producer and consumer threads.

Let's understand what we need first. If the queue is full, the producer needs to wait for a consumer to consume an item. Similarly, if the queue is empty, the consumer needs to wait until the producer pushes an item.

Also, when a producer pushes an item, it needs to notify all the waiting consumer threads about the action. The is also true when the consumer consumes an item. So, how do we establish this communication?

We can do this using the wait() and notify() methods. When the wait() method is called, the thread releases the lock on the object and enters a waiting state until another thread calls the notify() or notifyAll() method.

notify() wakes up one thread that is in the waiting state, while notifyAll() wakes up all waiting threads. When a thread wakes up again, it has to re-acquire the lock on the object. If another thread has the lock, then this thread needs to wait until the other thread releases the lock.

You can learn more about the wait() and notify() methods here .

How to Communicate Between Threads using wait() and notify()

Let's use the above methods. A producer needs to wait before it pushes an item if the queue is full. So, invoke the wait() method if the queue is at capacity. Similarly, the consumer needs to wait if the queue is empty.

To wake up threads from the waiting state, call notifyAll() after the producer publishes a message and the consumer consumer a message. This will notify all the waiting threads.

Here is the updated publish() method:

And here's the updated consume() method:

wait() and notify() can throw InterruptedException , so we add a throws declaration to the methods.

This time, the output is more consistent and we are getting the expected behavior. The producer keeps publishing messages and the consumer consumes those messages.

Here, the queue is full and the producer waits for the consumer to consume a message. Only after that does the producer publish a new message.

So far, we have tackled the problem with one producer and one consumer. In a real-world application, there could be multiple producers and consumers, all of them running in separate threads.

Let's add more consumer threads to see how we could handle this scenario:

Here, we have created 5 consumer threads, labelled them, and started them one by one. But, this is not enough. There is an issue with the existing approach.

Let's reduce the consumer sleep time and run the code:

Here, after consumer 5 has consumed a message, the other consumers are able to consume even if the queue is empty.

The issue lies in the following condition:

Let's understand the workflow first. Consider Consumer 5 (C5) and Consumer 1 (C1). C5 secures the lock on the method and enters it. The queue is initially empty, so it releases the lock and waits for the producer. At the same time, C1 secures the lock and enters the method. It also waits for the producer.

So, C5 and C1 are waiting. The producer publishes a message. C5 and C1 are notified and they wake up. C5 reacquires the lock and proceeds to consume the message, while C1 waits for C5 to release the lock. Here, C1 is not waiting because of wait() – it has woken up and now it's waiting at the next line.

After C5 consumes the message and releases the lock, C1 continues and tries to consume the message. But the queue is empty now, so it receives null or throws an exception. This also happens with the other threads.

To prevent this, we need to check if the queue is empty once again. So, instead of using an if condition, we use a while loop like this:

This checks if the queue is empty every time a thread wakes up. So, if multiple threads wake up at the same time, it should check if another thread has emptied the queue.

We do the same for checking if the queue is full.

This time, the code runs without any issues.

Here is the complete code for Data class:

You can create any number of producers and consumers and test this code in multiple scenarios.

So far you have learned what the producer-consumer problem is and how it can be solved. But, while working on real-time applications, we probably won't implement synchronization manually.

Instead, we can use the BlockingQueue class from java.util.concurrent package. The difference between Queue and BlockingQueue is that it waits for the queue to become non-empty before a message can be consumed. Similarly, it waits for the queue to have space before publishing a new message.

We can initialize the blocking queue in the following way:

This creates a blocking queue of capacity 10. To publish an item, we use the put() method, and to remove an item, we use the take() method.

Let's first use this in our Producer class:

Here, we are not using a separate Data class with synchronized methods, since the put() and take() methods of BlockingQueue are synchronized. Here, if the queue is full, the put() method waits for a consumer to consume a message.

Similarly, let's update our Consumer class:

Here, if the queue is empty, the take() method waits for the producer to publish a message.

Let's create our BlockingQueue object and start these threads:

Here, we have one producer thread and 5 consumer threads. Let's see the output:

In the output, you can see that after consumers 1, 3, and 2 have consumed a message, the other consumers wait for a message to be published before consuming it.

There could be a few inconsistencies while printing these messages since the thread only stops at the put() or take() methods and not the println() statements. But the code runs properly. Again, the output will be different each time you run the code.

So, while working on big projects, you can use the BlockingQueue class. But it's important to understand how to deal with the whole producer-consumer problem from scratch. This is really helpful, especially during interviews, since you typically won't be allowed to use the BlockingQueue class.

In this tutorial, you learned about an important problem in concurrency, the product-consumer problem. And you learned how you can solve it using multithreading in Java.

In total, we implemented four different approaches:

First, I started out with a very basic and straightforward implementation. Running the producer and consumer in separate threads helped achieve concurrency. But since they used the same message queue, there was a synchronization problem.

Therefore, in the next approach, we added synchronization to fix the issue. Then, we added more consumers who would all wait for the producer. There, we learned why it is important to check the full and empty conditions every time a thread wakes up.

After going through the whole implementation from scratch, we saw a simple way to solve the Producer-Consumer problem in Java using BlockingQueue. By understanding different approaches and their issues, you can get a better idea of how to tackle a problem. I hope this guide helps with your future endeavors.

If you are unable to understand the content or find the explanation unsatisfactory, let me know. New ideas are always appreciated! Feel free to connect with me on Twitter. Till then, goodbye!

Read more posts .

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started

8.3. Producer-Consumer Problem ¶

One of the most common task structures in concurrent systems is illustrated by the producer-consumer problem . In this problem, threads or processes are divided into two relative types: a producer thread is responsible for performing an initial task that ends with creating some result and a consumer thread that takes that initial result for some later task. Between the threads, there is a shared array or queue that stores the results being passed. One key feature of this problem is that the consumer removes the data from the queue and consumes it by using it in some later purpose. There is no way for the consumer thread or threads to repeatedly access data in the queue.

As an example, consider a researcher who discovers a previously unknown play and they believe it may have been written by a famous author. As part of their work, this researcher wants to know if the newly discovered text uses common words with the same frequency that author used in other works. This work could be done with a pipe-and-filter application that reads in the content of the texts, builds a search index of all words based on their frequency, performs some computation that compares the search indexes of all of the works. One thread is assigned the tasks of reading in the contents and producing the list of words, placing a word at a time in a queue. A second thread consumes the words by removing them from the queue and adding them to the data used to build the search index. This thread then becomes a producer because it provides the index to yet another thread that will be performing the index comparisons.

8.3.1. Producer-Consumer with Unbounded Queue ¶

As a first variant on this problem, consider two threads that share an unbounded queue. This approach can be implemented using a linked list approach for the queue. Specifically, we can assume that there is a queue_t structure that contains pointers to the front and back of the queue, where the nodes in the queue are of type queue_node_t . The nodes all contain pointers to some sort of data_t field. Code Listing 8.10 shows the framework for enqueueing and dequeueing data.

This implementation, which would be acceptable for a single-threaded application, has a race condition when used in a concurrent setting. Specifically, if one thread begins to enqueue() some data, another thread that tries to dequeue() the data at the same time may get a NULL pointer because the first thread has not yet reached the line the advances the back pointer.

The solution here would be to refactor these functions to become a monitor as shown in Code Listing 8.11 . Each function would be passed a reference to a shared mutex that would be locked on entry and released just before the function returns. This solution eliminates the race condition regarding the timing of access to the queue’s back field. Additionally, this solution is generalizable regardless of the number of producers and consumers. If there are multiple producers trying to enqueue() data, the mutex ensures that they will not try to manipulate the queue at that same time. For brevity, Code Listing 8.11 calls the functions from Code Listing 8.10 .

8.3.2. Single Producer-Single Consumer Solution Using a Bounded Queue ¶

In many cases, the unbounded queue of the previous section is neither feasible nor desirable. For instance, this approach makes it very easy to launch a denial-of-service attack against the application, particularly if this code is used in a server. Code Listing 8.12 shows a single line of code that quickly exhausts the program’s dynamic memory resources, leading to a system crash.

Given this weakness, systems software typically imposes constraints on the number of items in the queue. One approach would be to use semaphores with the linked list queue above. Another approach is to use a finite circular array as the basis. For this approach, we will still assume the use of a queue_t data type to represent the queue, however the internal implementation uses an array instead of linked nodes. Figure 8.3.1 illustrates the structure of the queue.

Figure 8.3.1: A circular queue using an array

Code Listing 8.13 shows the unsafe version of the enqueue() and dequeue() operations for an array implementation of a queue. Within the queue_t data type, contents is an array of pointers to the enqueued data, while front and back are indexes into this array. When either of the indexes are incremented, the operations must recalculate the value modulo the array size to ensure that the values stay within the bounds of the array. This approach creates a circular structure, where the spaces in the array can be reused. Once the back index reaches the end of the array, it would return to the first position and continue from there.

The implementation in Code Listing 8.13 has a fundamental flaw in both operations, as neither enforces the limited capacity. This design choice was intentional, as this code was meant to encapsulate the enqueueing and dequeueing behavior. That is, we can now reason through the synchronization issues for the producer-consumer problem without regard for the specific queue implementation.

To build the rationale for the solution to the producer-consumer problem, consider Code Listing 8.14 . This implementation attempts to keep track of the number of items ( queue->size ) in the queue, comparing it with values that indicate whether the queue is full or empty.

The attempted solution in Code Listing 8.14 fails because it has race conditions on the queue’s counter variable. If the producer is attempting to enqueue an item at the same moment the consumer is dequeueing one, the outcome depends on whether the producer’s check for available space happens before or after the consumer decrements the counter . A similar race condition arises if the queue is empty and both functions are called. This race condition could be fixed by wrapping the accesses to the counter with a mutex.

Code Listing 8.14 has another flaw from the producer’s perspective: there is no indication that there was a failure to enqueue the item . Addressing this failure would require changing the function’s interface to return a status to indicate success or failure. This approach, however, imposes an undesirable burden on the user. That is, the programmer who is building the producer and consumer threads or processes must build in a fail-safe mechanism to respond accordingly if the enqueue() or dequeue() operations fail.

A better, more user-friendly solution to the producer-consumer problem is to use semaphores. Note that semaphores incorporate the key functionality that we need: atomic incrementing and decrementing of a counter variable . The previous approach was trying to re-invent this already-solved problem. Code Listing 8.15 shows the framework for solving the producer-consumer problem for a single producer and single consumer.

The structure of this approach is to use signaling with two semaphores. The key insight here is that there are actually two bounds that need enforced: a maximum and a minimum. If the queue is full, then the producer needs to wait until there is a space available. That is, the producer must call sem_wait(space) and wait if necessary. The space semaphore is initialized to the capacity of the queue, so it would only be 0 if that many items are already in the queue. Once the consumer has removed an item from the queue, it performs the counterpart call sem_post(space) to alert the producer that a space is available. In short, the space semaphore enforces the maximum capacity of the queue.

At the same time, the consumer must not attempt to remove an item from the queue if none have been enqueued. Depending on the internal state of the queue, this attempt to dequeue an item might return old data that has previously be removed or an unexpected NULL pointer. The items semaphore, which is initialized to 0 and represents the number of enqueued items, enforces this constraint. If the queue is empty, this semaphore would have an internal value of 0, causing the consumer to block when it calls sem_wait(items) . Once the producer puts an item into the queue, it would perform the corresponding sem_post(items) that would increment the semaphore and unblock the consumer.

8.3.3. Multiple Producers Solution Using a Bounded Queue ¶

The solution in the previous section works successfully if there is only a single producer. However, if there are multiple producers, the previous solution will not work and should not be used. The problem is the line highlighted in Code Listing 8.16 . Recall that post-increments in C are not atomic operations. That is, the internal execution at the machine language level involves a three-step process: load the value into a register, increment the value in the register, and store the result back into memory. If two threads try to perform this increment at the same time, the increments could interfere with each other.

The solution in this case would be to add a lock as shown in Code Listing 8.17 . Acquiring and releasing the lock as shown here minimizes the size of the critical section. That is, the operations on the semaphores do not require protection. Including the calls to sem_wait() and sem_post() within the critical section for the lock would unnecessarily prevent the other producers from manipulating the semaphores, partially eliminating the benefit of using a semaphore.

Note that this approach does not require any modification to the dequeue() operation used by the consumer. Since there is only a single consumer, there is no race condition on incrementing the queue->front variable. This solution could be extended to multiple consumers by introducing a second lock for consumers used in dequeue() as shown in Code Listing 8.18 . It is important, in this case, to use separate locks rather than simply reusing the same lock for both producers and consumers. When both the space and items semaphores have positive values, then the front and back of the queue are guaranteed to be in different places. That is, there are multiple items in the queue, so the producer and consumer within the critical sections would not be interfering with each other. Consequently, there is no reason that the producer needs to lock out the consumer, or vice versa.

DEV Community

Posted on Jun 27, 2023

How to solve the producer-consumer problem in Java — vivid example (multithreading)

Hello guys, in the previous tutorial , we created a simple program that consisted of DonutStorage, and a Consumer who consumed donuts. We had multiple consumers run by different threads at the same time. We had to synchronize them to solve a race condition.

But what if we also want to include producers? We’ll first need to change the app to follow the best OOP practices. Second, we’ll get a producer-consumer problem, find out what it is, and solve it with wait and notify methods. Then we’ll learn how it can be easily done with BlockingQueue . Let us begin!

Table of Contents

 1. Adding producers  2. Producer-consumer problem  3. Wait and notify        1) On what object to call the methods        2) What’s an InterruptedException        3) What happens when a thread meets the wait method        4) What happens when the thread gets notified        5) Why use notifyAll over notify        6) The importance of keeping wait within a while loop        7) When should you notify?

 4. BlockingQueue  5. BlockingQueue vs wait and notify  6. Further reading

Adding producers

Code recap from the previous tutorial:

So we have the DonutStorage with a single variable donutsNumber , getters and setters for it, and a constructor. We also have the Consumer class, which has its instance of DonutStorage and a single method for consuming items. In the Main class, we create a DonutStorage with the initial donutsNumber equal to 20. Then, we create 10 separate threads. Each creates a new Consumer and consumes 3 items. In addition, we want to print how many donuts are left before the program exits, but to make this work, we need to create a list of futures and loop through them. This way, the main thread will wait until the others finish.

To add producers, let’s first figure out what they are going to do. They will simply add the number specified in the param to the donutsNumber . But we also want some protection because the storage probably has some limits. So let’s also add a donutsCapacity field to the DonutStorage . And before updating the donutsNumber , we’ll check if there is enough space to add this number of donuts. If not, we’ll add as many as possible and return the number of added donuts. Here is the code:

But it wouldn’t be a good decision to create a separate class called Producer . That’s because the Producer and Consumer classes would be almost identical. They would both have a DonutStorage instance and a single method with the same argument. The only thing that would be different is the operation they would do, which would be defined in the body of that method. In addition, the operation should be done synchronously, which would be difficult to realize using a superclass and its subclasses.

That’s why I propose creating one class and passing the operation it’s meant to do in the constructor. To achieve this in Java, we’ll need to create a FunctionalInterface and pass its instance in the constructor (ala functional programming):

This way, when someone creates a Client , they will have to specify the operation they want the Client to do. And this also guarantees that the operation will be done synchronously because of the synchronized block within the operate method.

For now, we plan the Client to be either a producer or a consumer, whereas other classes are allowed to define their own functionality of the Client . To avoid writing boilerplate code and possibly some bugs in the future, let’s define this functionality right inside the Client class. We can achieve this using public static final variables:

Here lambdas shorten the code of creating a new instance of ClientOperation and overriding the operate method.

And finally, let’s make the ClientOperation private. This way, we’ll restrict defining a custom functionality to the Client . It will either produce or consume items.

Now we don’t need the Consumer class anymore. The only thing left is to make minor changes to the Main class:

You can compare the old and the updated versions here .

Producer-consumer problem

Now let’s test our program. Let’s create 10 consumers, each consuming 5 items, and 5 producers, each producing 6 items.

The initial number of donuts in the storage is 20. So we expect the remaining number of items to be 0. But in reality, I get the resulting number equal to 30. Here is the full output:

What happened is all the consumers finished their work (consumed 20 items) before the producers came and added 30 extra donuts. And these events weren’t printed in the order because of the thread interleaving.

Wait and notify

The problem can be solved with wait and notify . They are methods of the Object class that block the current thread until it gets notified. So we could just call wait on the consumer threads when there are not enough items in the stock, and notify them when we are sure that the stock is not empty anymore. Similarly, we could block the producers when the storage is full and notify them, when a consumer takes an item.

So is that how the updated consumer part would look like?

Unfortunately, it’s not that easy. We must consider the following:

1. On what object to call the methods

The code above would end with the exceptions:

It also wouldn’t work if we defined separate objects that represent the fullness and emptiness of the storage. We would get an

IllegalMonitorStateException – thrown if the current thread is not the owner of the object's monitor.

This phrase is written so clearly that we don’t understand anything. But I hope to clear it up in a moment ⬇️

If we were allowed to call wait() and notify() on some random object we would end up with lots of bugs. That’s because we may have another part of the program where other threads are waiting for something else to happen.

The exception means that they want us to call wait and notify on that object we synchronized our method on. In our case, it’s the donutStorage . If we call it on another object, it will not work. It also won’t work if we call the methods in an unsynchronized block of code.

2. What’s an InterruptedException

We are obliged to handle this exception that may be thrown by the wait method. It’s an exception that indicates that someone canceled the operation or the OS wants to terminate the thread. If that happens, the thread does not finish its work. It will do what is written in the try/catch block. Read more about how to handle InterruptedException .

In our case, we will just print that the thread was interrupted and return the number of consumed/produced items.

3. What happens when a thread meets the wait method

When the wait method is called, the first thing the thread does is release the lock it has held. Otherwise, other threads would be waiting for that lock and will not be able to update the variable. And the program would come to a deadlock situation.

4. What happens when the thread gets notified

The thread continues its work from that line of code with the wait method. So we should write some code to execute after that. In our case, the consumer will consume the rest of the items:

Mind you that we no longer use a local variable as a contraction for donutStorage.getDonutsNumber() . That’s because this variable is no longer constant as the thread calling the wait() method releases the lock and the donutsNumber gets updated by other threads.

5. Why use notifyAll over notify

Another method is notifyAll() , which wakes up all the threads that are waiting. This is different from notify() , which only wakes up one random thread from the wait set. notify() is more efficient, but it has a risk. If the chosen thread cannot continue, it will be blocked again. If no other thread calls notify() again, the system will deadlock .

6. The importance of keeping wait within a while loop

So it’s better to use notifyAll() . This brings another problem. When one of the multiple consumers gets notified, it might consume some items, leaving the others with insufficient items.

Even though the access to the donutStorage is synchronized, a thread may acquire a lock, and consume items. When another thread acquires that lock, it will continue from that line of code where the wait method is and will not double-check the condition. So, for preventing that, it’s recommended to always put the wait method in the while loop, even when you use notify .

7. When should you notify?

The rule of thumb is to use notify whenever the object's state changes in a way that could benefit the threads that are waiting. For example, when the numberOfDonuts changes, the waiting threads should have another opportunity to check it.

With all being said, here is the updated code ⬇️. You can also compare the old and the updated versions here .

BlockingQueue

The code above runs well, and we’ve fixed the issue. But there is another one. When consumers want more items than producers ever put, the program will run infinitely. That’s because the consumers will wait for more producers to put some items. But all the producers may have already finished their work. The same will happen if producers want to put more items than the storage can hold, and all the consumers have left and don’t need more items.

You can check it yourself by setting the producers' number to 5, the consumers' number to 10, and let them produce and consume 10 items each. Make sure that the initial `donutsNumber' is 20. The program will run infinitely.

This can be solved by specifying the time the producers and consumers will wait before they finish. But the program has got very complicated and I’m eager to introduce a simpler and more effective solution — BlockingQueue .

This basically does all the inter-thread communication and synchronization for us. It’s very easy to implement. BlockingQueue stores all the items in an array. When the array is empty, it internally blocks all the consumers and notifies them when some items have been added. A similar is done with the producers.

The primary methods for putting into the queue and taking from it are put and take . But I use offer and poll to solve the problem described above. They put one item into the queue or take one from it. I also use add to initially populate the queue with some items.

You can find the final code on my GitHub. Make sure to star the repo! ⭐

DanielRendox / ThreadSynchronizationInJava

A simple learning project that demonstrates ways to solve such multithreading problems as race conditions, deadlocks, and producer-consumer problem.

ThreadSynchronizationInJava

The project forms the basis of the following tutorials:

• What is a Race Condition in Java, and how it can be prevented using synchronized and AtomicInteger
• How to solve the producer-consumer problem in Java

BlockingQueue vs wait and notify

There are various tools like BlockingQueue out there that provide a simple and effective solution to the producer-consumer problem. It’s not recommended to use old-school wait and notify for this purpose as they require special effort and your code will be bug-prone as opposed to well-tested ready solutions.

However, wait and notify provide more flexibility and control over the synchronization mechanism. For example, using BlockingQueue is designed to work with custom objects. So ideally, we would create a class called Donut for that and put these donuts into the queue. But we don’t need them. What only matters in our program is the number of items not getting bigger than the capacity and not getting negative. So in our case, we waste some resources on creating an array of simple empty Objects. But even so, the pros justify the cons.

Nevertheless, if that’s not true for your app, it may be reasonable to use such tools as wait and notify. The reason why it’s the most popular solution to the producer-consumer problem is that it’s easier to understand inter-thread communication using wait and notify. You may also get asked to solve a producer-consumer problem with wait and notify on your interview.

I hope you learned how to solve a producer-consumer problem from this tutorial. Put a unicorn 🦄 on this article to indicate that you managed to read the whole post. Your and my effort should be seen! See you later!

Further reading

Check out my other articles about multithreading in Java:

🤯 Thread, Runnable, Callable, ExecutorService, and Future - all the ways to create threads in Java

Daniel rendox ・ jun 7 '23, 🛡️ what is a race condition in java, and how it can be prevented using synchronized and atomicinteger, daniel rendox ・ jun 17 '23.

And some other useful resources as well:

• Java: Handling InterruptedException | Programming.Guide
• Cay Horstmann's Core Java book - the chapter about synchronization available for free

Top comments (0)

Templates let you quickly answer FAQs or store snippets for re-use.

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

2373. Largest Local Values in a Matrix

MD ARIFUL HAQUE - May 12

VS Code Extension that will make your coding life easy

bingecoder89 - May 12

Is null a dataType in Javascript?

Maulik Chaudhary - May 12

Complete portfolio using HTML

chaitanya kolla - May 12

We're a place where coders share, stay up-to-date and grow their careers.

The Producer-Consumer Problem & POSIX Condition Variables

• The Producer-Consumer Problem
• Introduce condition variables and show how they can be used to solve the Producer-Consumer Problem

Producer-Consumer Problem

• One or more threads generate data and put it into a buffer
• One or more threads take data items from the buffer, one at time
• Only one producer or consumer may access the buffer at any one time
• Single producer & single consumer
• Multiple producers & single consumer
• Multiple producers & multipole consumers

Why are buffers called "buffers"? (How does a buffer relate to a pancake? How does a chemical buffer relate to a computer buffer?

What are examples of situations on an operating system that require buffers?

How are buffers in different layers of a system? Consider hardware device drivers, the file system, and user programs.

Significance of the Producer-Consumer Problem

• It occurs frequently in real applications
• It is often used to illustrate and compare different mutual exclusion and synchronization mechanisms
• correctness of mutual exclusion
• generality (How many producers/consumers will it support?)
• simplicity of expression
• efficiency (execution time overhead)
• fairness, if there are multiple consumers/producers

Your textbook shows a graduated series of solutions to this problem using various mechanisms, including semaphores. Here, we will use the POSIX thread synchronization mechanisms, instead.

Using an Infinite Buffer

Infinite buffer, using a circular buffer, finite (circular) buffer, complete example program using a circular buffer.

See prodcons0.c for a complete program using a circular (ring) buffer and no other form of synchronization.

This solution works for a single producer and a single consumer, because the shared variables in and out have only a single reader and a single writer

It is a very important mechanism for those situations where it works, because:

• It is simple
• It requires no special mutual exclusion or synchronization mechanisms

It is especially useful for low-level device and systems programming, when the producer and consumer are executing on different physical processors.

A defect of this solution for other applications is that it wastes CPU time idling the processor.

Why is idling the processor a problem?

Why is it a special problem for library-level implementations of threads?

How to Avoid Unbounded Blocking with POSIX Threads

This will not help if we are using strict priority scheduling and the threads have different prioritys. Why?

A complete program illustrating this solution is given in file prodcons1.c .

Using a Mutexes with a Circular Buffer (simplified view)

We can use the producer-consumer example solution to explain the semantics of pthread_cond_wait() as well as to illustrate a style of designing with mutexes and CV's, which is derived from the "monitor" concept.

prodcons2.c Viewed as a Monitor: Mutex-Only View

When books explain monitors, they explain them as a programming language feature, because that is how the term was introduced. However, behind the monitor programming language concept there is an underlying design model that can be implemented without language. In particular, this design model is such a natural match with with mutexes and condition variables that one might say they were designed for one another.

A monitor starts with mutual exclusion, which can be implemented using a mutex. We can picture a collection of data objects that are protected by a mutex as a room with a door, with a guard posted at the door.

The mutex is the guard. It only allows one person (thread) into the room at a time. The pthread_mutex_lock(&M); call is used to go in, and the pthread_mutex_unlock(&M); call is used to exit.

prodcons2.c Viewed as a Monitor: Blocking

While one thread is in the room, the mutex prevents any other thread from entering. The figure shows what happens if a consumer thread tries to enter the room (by calling pthread_mutex_lock (&M); ) while the producer thread is still in the room. The consumer blocks, in the call to pthread_mutex_lock .

prodcons2.c Viewed as a Monitor: Buffer Full Picture

Continuing with this analogy to a room with a guard, the function of a condition variable can be understood as a waiting room. In the figure, the producer goes into the room and finds that the buffer is still full. It cannot proceed, so it call pthread_cond_wait (&In_CV, &M); . The effect is as if the calling thread leaves the protected room and goes into a side room, then goes to sleep.

When the thread leaves the room, the guard (the mutex) notices and will now allow another thread into the room. For example, tn the figure the consumer that was blocked on a call to pthread_mutex_lock will be unblocked and allowed to enter the room.

The thread that is waiting in the side room will wait there until it wakes up, at which point it will try to get back into the protected room. To do so, it will need to relock the mutex. It does not need to call pthread_mutex_lock() to do this. The un locking, sleeping, and then relocking are all part of the effect of the one call to pthread_cond_wait .

Semantics of pthread_cond_wait and pthread_cond_signal

• unlock the mutex
• sleep for a while (may wake up at any time)
• relock the mutex
• wake up at least one of the threads (if any) that is sleeping on the CV

The analogy to a person sleeping in a side room fits the pthread_cond_signal operation, too.

A thread that is waiting on a call to pthread_cond_wait may wake up at any time, just as a person who goes to bed may wake up before the alarm clock goes off.

When some other thread calls pthread_cond_signal for the given CV, the effect is similar to someone ringing a loud alarm bell in the side "room" that corresponds to the CV. If there is a thread waiting on a CV, it is guaranteed to wake up when that CV is signaled. If there are several threads waiting on the same CV, at least one is guaranteed to wake up. (Whether more than one wakes up depends on the implementation.) If there is no thread waiting on the CV, the pthread_cond_signal call has no effect.

prodcons2.c Viewed as a Monitor: Producer Early Wakeup

If the producer wakes up early, it will find there is still no space in the buffer, and it will go back to sleep again on In_CV .

prodcons2.c Viewed as a Monitor: Waking up the Producer

Eventually, the consumer, who was blocked trying to enter the room, will be allowed to enter and removes an item from the buffer. After the consumer has left the room, he calls pthread_cond_signal (&In_CV); . This will wake up the producer.

prodcons2.c Viewed as a Monitor: Producer After Wakeup

The producer inserts an item into the buffer, and then leaves the room by calling pthread_mutex_unlock . Before that, or immediately after, the producer needs to signal the condition variable on which the consumer(s) might be waiting.

prodcons2.c Viewed as a Monitor: Buffer Empty Picture

What have we gained by using pthread_cond_wait() instead of sched_yield() ?

This solution now supports multiple readers and multiple writers. However, it does not guarantee fairness. Is that important here?

Full programs illustrating this solution are given in files prodcons2.c . and prodcons3.c .

The latter is done in an object-oriented style. The buffer datatype contains its own mutex and condition variables. What is the advantage of having these synchronization objects be per-buffer?

Note: The above examples, and others, are all in the directory examples/prodcons .

There are some very interesting animated examples of solutions to the producer-consumer and readers-writers problems on the web. For example, there is a list of animations for operating systems concepts, including the producer-consumer problem, at http://williamstallings.com/OS-Animation/Animations.html . You may like to try executing some of them to get a better picture of how monitors, semaphores, etc. work. (Beware: To run them you may need to install some Java class libraries, and Java is notorious for version dependences.)

Producer Consumer Problem in OS

Producer-Consumer problem is a classical synchronization problem in the operating system. With the presence of more than one process and limited resources in the system the synchronization problem arises. If one resource is shared between more than one process at the same time then it can lead to data inconsistency. In the producer-consumer problem, the producer produces an item and the consumer consumes the item produced by the producer.

What is Producer Consumer Problem?

Before knowing what is Producer-Consumer Problem we have to know what are Producer and Consumer.

• In operating System Producer is a process which is able to produce data/item .
• Consumer is a Process that is able to consume the data/item produced by the Producer .
• Both Producer and Consumer share a common memory buffer. This buffer is a space of a certain size in the memory of the system which is used for storage. The producer produces the data into the buffer and the consumer consumes the data from the buffer.

So, what are the Producer-Consumer Problems?

• Producer Process should not produce any data when the shared buffer is full.
• Consumer Process should not consume any data when the shared buffer is empty.
• The access to the shared buffer should be mutually exclusive i.e at a time only one process should be able to access the shared buffer and make changes to it.

For consistent data synchronization between Producer and Consumer, the above problem should be resolved.

Solution For Producer Consumer Problem

To solve the Producer-Consumer problem three semaphores variable are used :

Semaphores are variables used to indicate the number of resources available in the system at a particular time. semaphore variables are used to achieve `Process Synchronization.

The full variable is used to track the space filled in the buffer by the Producer process. It is initialized to 0 initially as initially no space is filled by the Producer process.

The Empty variable is used to track the empty space in the buffer. The Empty variable is initially initialized to the BUFFER-SIZE as initially, the whole buffer is empty.

Mutex is used to achieve mutual exclusion. mutex ensures that at any particular time only the producer or the consumer is accessing the buffer.

Mutex - mutex is a binary semaphore variable that has a value of 0 or 1 .

We will use the Signal() and wait() operation in the above-mentioned semaphores to arrive at a solution to the Producer-Consumer problem.

Signal() - The signal function increases the semaphore value by 1 . Wait() - The wait operation decreases the semaphore value by 1 .

Let's look at the code of Producer-Consumer Process

The code for Producer Process is as follows :

Let's understand the above Producer process code :

• wait(Empty) - Before producing items, the producer process checks for the empty space in the buffer. If the buffer is full producer process waits for the consumer process to consume items from the buffer. so, the producer process executes wait(Empty) before producing any item.
• wait(mutex) - Only one process can access the buffer at a time. So, once the producer process enters into the critical section of the code it decreases the value of mutex by executing wait(mutex) so that no other process can access the buffer at the same time.
• add() - This method adds the item to the buffer produced by the Producer process. once the Producer process reaches add function in the code, it is guaranteed that no other process will be able to access the shared buffer concurrently which helps in data consistency.
• signal(mutex) - Now, once the Producer process added the item into the buffer it increases the mutex value by 1 so that other processes which were in a busy-waiting state can access the critical section.
• signal(Full) - when the producer process adds an item into the buffer spaces is filled by one item so it increases the Full semaphore so that it indicates the filled spaces in the buffer correctly.

The code for the Consumer Process is as follows :

Let's understand the above Consumer process code :

• wait(Full) - Before the consumer process starts consuming any item from the buffer it checks if the buffer is empty or has some item in it. So, the consumer process creates one more empty space in the buffer and this is indicated by the full variable. The value of the full variable decreases by one when the wait(Full) is executed. If the Full variable is already zero i.e the buffer is empty then the consumer process cannot consume any item from the buffer and it goes in the busy-waiting state.
• wait(mutex) - It does the same as explained in the producer process. It decreases the mutex by 1 and restricts another process to enter the critical section until the consumer process increases the value of mutex by 1.
• consume() - This function consumes an item from the buffer. when code reaches the consuming () function it will not allow any other process to access the critical section which maintains the data consistency.
• signal(mutex) - After consuming the item it increases the mutex value by 1 so that other processes which are in a busy-waiting state can access the critical section now.
• signal(Empty) - when a consumer process consumes an item it increases the value of the Empty variable indicating that the empty space in the buffer is increased by 1.

Why can mutex solve the producer consumer Problem ?

Mutex is used to solve the producer-consumer problem as mutex helps in mutual exclusion. It prevents more than one process to enter the critical section. As mutexes have binary values i.e 0 and 1. So whenever any process tries to enter the critical section code it first checks for the mutex value by using the wait operation.

wait(mutex);

wait(mutex) decreases the value of mutex by 1. so, suppose a process P1 tries to enter the critical section when mutex value is 1 . P1 executes wait(mutex) and decreases the value of mutex. Now, the value of mutex becomes 0 when P1 enters the critical section of the code.

Now, suppose Process P2 tries to enter the critical section then it will again try to decrease the value of mutex. But the mutex value is already 0 . So, wait(mutex) will not execute, and P2 will now keep waiting for P1 to come out of the critical section.

Now, suppose if P2 comes out of the critical section by executing signal(mutex) .

signal(mutex)

signal(mutex) increases the value of mutex by 1. mutex value again becomes 1 . Now, the process P2 which was in a busy-waiting state will be able to enter the critical section by executing wait(mutex) .

So, mutex helps in the mutual exclusion of the processes.

In the above section in both the Producer process code and consumer process code, we have the wait and signal operation on mutex which helps in mutual exclusion and solves the problem of the Producer consumer process.

Dive into the world of operating systems with our free Operating System course . Join today and acquire the skills from industry experts!

• Producer Process produces data item and consumer process consumes data item.
• Both producer and consumer processes share a common memory buffer.
• Producer should not produce any item if the buffer is full.
• Consumer should not consume any item if the buffer is empty.
• Not more than one process should access the buffer at a time i.e mutual exclusion should be there.
• Full, Empty and mutex semaphore help to solve Producer-consumer problem.
• Full semaphore checks for the number of filled space in the buffer by the producer process
• Empty semaphore checks for the number of empty spaces in the buffer.
• mutex checks for the mutual exclusion.

Operating System

• Interview Q

Process Management

Synchronization, memory management, file management.

• Send your Feedback to [email protected]

Help Others, Please Share

Learn Latest Tutorials

Transact-SQL

Reinforcement Learning

R Programming

React Native

Python Design Patterns

Python Pillow

Python Turtle

Preparation

Verbal Ability

Interview Questions

Company Questions

Trending Technologies

Artificial Intelligence

Cloud Computing

Data Science

Machine Learning

B.Tech / MCA

Data Structures

Computer Network

Compiler Design

Computer Organization

Discrete Mathematics

Ethical Hacking

Computer Graphics

Software Engineering

Web Technology

Cyber Security

C Programming

Control System

Data Mining

Data Warehouse

Producer-Consumer Problem in Python

Hello everyone! In this tutorial, we will learn about the Producer-Consumer problem which is a classical problem of concurrency and how to solve it using Python Threads. So let’s get started.

Also read: How to create custom datasets in Python?

What is Producer-Consumer Problem?

Producer-Consumer Problem consists of 3 components:

1. Bounded Buffer

A buffer is temporary storage that is accessible by different threads. A simple example of a buffer is an array. Multiple threads can read the data from the buffer as well as can write the data to the buffer concurrently. A bounded buffer is one that has a limited capacity and can’t store the data beyond its capacity.

2. Producer Thread

A Producer Thread is one that generates some data, puts it into the buffer, and starts again until all the data needed is not produced. An example of this could be a thread that downloads some data over the network and stores it temporarily into the buffer

3. Consumer Thread

A Consumer Thread is one that consumes the data present inside the buffer, uses it for some task, and starts again until the task assigned to the thread is not completed. An example of this could be a thread that reads the data that is downloaded over the internet and stores it in the database.

What happens when the operating rate for threads is different?

The speed of the operations done by the threads can vary depending on the tasks assigned. So, in our case, either our Producer Thread might be slow as compared to Consumer Thread or Producer Thread might be fast in generating data as compared to the speed at which Consumer Thread is consuming.

If the rate at which threads are operating is different, there might be some issues and that’s what Producer-Consumer Problem says.

• If the Producer Thread is trying to generate the data into the buffer and found that the buffer is already full, the Producer Thread can neither add more data inside the buffer nor it can overwrite the existing data that has not been consumed by the consumer yet. Therefore, the Producer Thread should stop itself until some data is not consumed from the buffer. This scenario might be possible if the Producer Thread is fast.
• If the Consumer Thread is trying to consume the data from the buffer but found that the buffer is empty, the Consumer Thread can’t take the data and it should stop itself until some data is not added into the buffer. This scenario might be possible if the Consumer Thread is fast.
• Since the buffer is shared among different threads that can access the data from the buffer simultaneously, race conditions are possible and both threads should not access the shared buffer at the same time. Either the Producer Thread should add the data to the buffer and the Consumer Thread should wait or the Producer Thread should wait while the Consumer Thread is working on shared buffer to read the data.

Solution to the problem using Semaphore

We can solve this problem with the help of Semaphores , which is a tool for synchronization between threads. We maintain 3 Semaphores in order to tackle 3 issues defined in our problem statement of the Producer-Consumer problem.

• empty: This semaphore stores the number of slots that are empty in our buffer. The initial value of this semaphore is the size of our bounded buffer. Before adding any data in the buffer, the Producer thread will try to acquire this semaphore and will decrease its value by 1. If the value of this semaphore is already 0, this means that the buffer is full and our empty semaphore will block the Producer Thread until the value of the empty semaphore becomes greater than 0. Similarly, after the Consumer Thread has consumed the data from the buffer, it will release this semaphore, increasing the value of the semaphore by 1.
• full: This semaphore stores the number of slots that are full in our buffer. The initial value of this semaphore is 0. Before consuming the data from the buffer, the Consumer Thread will try to acquire this semaphore. If the value of this semaphore is already 0, this means that the buffer is already empty and our full semaphore will block the Consumer Thread until the value of the full semaphore becomes greater than 0. Similarly, the Producer Thread will release this semaphore after it has added one item in it.
• mutex: This semaphore will handle the race condition by allowing only one semaphore to operate on the shared buffer at a time. The initial value of this semaphore is 1. Before operating on the shared buffer, both threads will try to acquire this semaphore. If any thread found the value of this semaphore as 0, this means that the other thread is operating on the buffer and it will be blocked by the semaphore. After operating on the buffer, the working thread will release this semaphore so that the other thread can operate on the buffer.

We also maintain 2 pointer to help our threads where to add or take the data.

• in pointer: This pointer will tell our Producer Thread where to add the next data in the buffer generated by the producer. After adding, the pointer is incremented by 1.
• out pointer: This pointer will tell our Consumer Thread where to read the next data from the buffer. After reading, the pointer is incremented by 1.

Implementing Producer-Consumer Problem in Python

Let us check the implementation on how to solve this problem in Python. Say we have a bounded buffer of capacity 10. The Producer Thread will produce 20 items and the Consumer Thread will consume those 20 items produced by the Producer. Adding time.sleep(1) in Producer and time.sleep(2.5) in Consumer makes our Producer Thread operate faster than Consumer Thread. Even if we are starting our Consumer Thread first, it will wait till there is no data present in our buffer.

Congratulations! Now you know how to solve the classical Producer-Consumer problem. There are many real life examples where similar situations can occur, like printing a document where multiple applications want to print a document, downloading the data over the network and storing in a database, etc.

Thanks for reading!!

• Selected Reading
• UPSC IAS Exams Notes
• Developer's Best Practices
• Questions and Answers
• Effective Resume Writing
• HR Interview Questions
• Computer Glossary

Producer-Consumer Problem in C

In concurrent programming, concurrency represents a pivotal concept necessary to comprehend fully how such systems operate. Among the various challenges encountered by practitioners working with these systems stands out the producer-consumer problem - one of the most renowned synchronization issues. In this text, our objective consists of analyzing this topic and highlighting its significance for concurrent computing while also examining possible solutions rooted within C.

Introduction

In concurrent systems, multiple threads or processes may access shared resources simultaneously. The producer-consumer problem involves two entities: producers that generate data or tasks, and consumers that process or consume the generated data. The challenge lies in ensuring that producers and consumers synchronize their activities to avoid issues like race conditions or resource conflicts.

Understanding the Producer-Consumer Problem

Problem statement.

One possible definition of the producer-consumer problem involves two main groups: producers of data who store their work in a communal space called the buffer, and processors (consumers) of that content saved in said space. These people use their expertise around gathered items within this temporary holding scenario to analyze it comprehensively before delivering insightful results.

Synchronization Requirements

Achieving resolution of the producer-consumer conundrum will necessarily involve implementing techniques for synchronized collaboration among all stakeholders involved. The integration of optimal synchronization protocols is fundamental in avoiding scenarios where device buffers are either overloaded by producing units or depleted by consuming ones.

Implementing the Producer-Consumer Problem in C

Shared buffer.

In C, a shared buffer can be implemented using an array or a queue data structure. The buffer should have a fixed size and support operations like adding data (producer) and retrieving data (consumer).

Synchronization Techniques

Several synchronization techniques can be used to solve the producer-consumer problem in C, including  −

Mutex and Condition Variables − Mutexes provide mutual exclusion to protect critical sections of code, while condition variables allow threads to wait for specific conditions to be met before proceeding.

Semaphores − Semaphores can be used to control access to the shared buffer by tracking the number of empty and full slots.

Monitors − Monitors provide a higher-level abstraction for synchronization and encapsulate shared data and the operations that can be performed on it.

Solutions to the Producer-Consumer Problem in C

Bounded buffer solution.

One common solution to the producer-consumer problem is the bounded buffer solution. It involves using a fixed-size buffer with synchronization mechanisms to ensure that producers and consumers cooperate correctly. The capacity for item production is limited by the buffer size making it crucial to factor in this specification so as not to exceed the available space in the buffer.

Producer and Consumer Threads

In C, the producer and consumer activities can be implemented as separate threads. Each producer thread generates data and adds it to the shared buffer, while each consumer thread retrieves data from the buffer and processes it. Synchronization mechanisms are used to coordinate the activities of the threads.

Handling Edge Cases

In real-world scenarios, additional considerations may be necessary. For example, if the producers generate data at a faster rate than the consumers can process, buffering mechanisms like blocking or dropping data may be required to prevent data loss or deadlock situations.

Two example codes in C to illustrate the implementation of the producer-consumer problem

Bounded Buffer Solution using Mutex and Condition Variables with Termination Conditions.

In this example, a bounded buffer solution for the producer-consumer problem is implemented using mutex and condition variables. The producer thread generates items and adds them to the buffer, while the consumer thread retrieves and consumes items from the buffer. The mutex ensures mutual exclusion while accessing the buffer, and the condition variables (full and empty) coordinate the producer and consumer threads. Termination conditions are added to limit the number of produced and consumed items.

Bounded Buffer Solution using Semaphores with Termination Conditions

In this example, a bounded buffer solution for the producer-consumer problem is implemented using semaphores. Semaphores are used to control access to the buffer and synchronize the producer and consumer threads. The mutex semaphore ensures mutual exclusion, full semaphore tracks the number of items in the buffer, and empty semaphore keeps track of the available empty slots in the buffer. Termination conditions are added to limit the number of produced and consumed items.

The producer-consumer problem is a significant challenge in concurrent programming. By understanding the problem and employing appropriate synchronization techniques, such as mutexes, condition variables, semaphores, or monitors, it is possible to develop robust solutions in the C programming language. These solutions allow producers and consumers to work together harmoniously, ensuring efficient data generation and consumption in concurrent systems.

Related Articles

• Producer Consumer Problem using Semaphores
• Producer-Consumer Problem and its Implementation with C++
• What is the shared memory concept by using producer consumer problem?
• Producer Consumer Solution using BlockingQueue in Java Thread
• Difference between Consumer Surplus and Producer Surplus
• Explain the terms ‘producer’ and ‘consumer’. Give two examples of producers and two of consumers.
• If a grasshopper is eaten by a frog, then the energy transfer will be from : producer to decomposerproducer to primary consumerprimary consumer to secondary consumersecondary consumer to tertiary consumer
• Partition Problem in C++
• Fitting Shelves Problem in C++
• Friends Pairing Problem in C++
• Corrupt stack problem in C, C++ program
• 0-1 Knapsack Problem in C?
• Water and Jug Problem in C++
• Minimum Word Break Problem in C++
• 2-Satisfiability(2-SAT) Problem in C/C++?

Kickstart Your Career

Get certified by completing the course

To Continue Learning Please Login

Introduction To OS

• Introduction to Operating System
• Evolution of Operating System
• Types of Operating System

Process & MultiThreading

• Operating System Processes
• Process Scheduling

CPU Scheduling

• First Come First Serve
• Shortest Job First
• Priority Scheduling
• Round Robin Scheduling
• Multilevel Queue Scheduling
• Multilevel Feedback Queue Scheduling
• Comparision of Scheduling Algorithms
• Introduction to Threads
• Process Synchronization
• Classical Synchronization Problems

Bounded Buffer Problem

• Dining Philosophers Problem
• Readers Writer Problem
• Semaphores in OS
• Classical Problems of Synchronization
• Deadlock Prevention in OS
• Deadlock Avoidance in OS
• Deadlock Detection and Recovery
• HRRN Scheduling
• Shortest Remaining Time First
• Longest Job First Scheduling
• Longest Remaining Time First Scheduling
• Memory Management
• Partition Allocation Methods
• Virtual Memory
• File System
• Banker's Algorithm
• Secondary Storage
• Resource Allocation Graph
• System Calls
• Logical and Physical Address
• Swapping in OS
• Contiguous Memory Allocation
• Paging in OS
• Page Table in OS
• Segmentation in OS
• Paging Vs Segmentation
• Contiguous Vs Non-Contiguous
• Paging Vs Swapping
• Internal Vs External Fragmentation
• Virtual Memory in OS
• Demand Paging in OS
• Copy on Write in OS
• Page Fault in OS
• Page Replacement Algorithm
• Thrashing in OS

Bounded buffer problem, which is also called producer consumer problem , is one of the classic problems of synchronization. Let's start by understanding the problem here, before moving on to the solution and program code.

What is the Problem Statement?

There is a buffer of n slots and each slot is capable of storing one unit of data. There are two processes running, namely, producer and consumer , which are operating on the buffer.

A producer tries to insert data into an empty slot of the buffer. A consumer tries to remove data from a filled slot in the buffer. As you might have guessed by now, those two processes won't produce the expected output if they are being executed concurrently.

There needs to be a way to make the producer and consumer work in an independent manner.

Here's a Solution

One solution of this problem is to use semaphores. The semaphores which will be used here are:

• m , a binary semaphore which is used to acquire and release the lock.
• empty , a counting semaphore whose initial value is the number of slots in the buffer, since, initially all slots are empty.
• full , a counting semaphore whose initial value is 0 .

At any instant, the current value of empty represents the number of empty slots in the buffer and full represents the number of occupied slots in the buffer.

The Producer Operation

The pseudocode of the producer function looks like this:

• Looking at the above code for a producer, we can see that a producer first waits until there is atleast one empty slot.
• Then it decrements the empty semaphore because, there will now be one less empty slot, since the producer is going to insert data in one of those slots.
• Then, it acquires lock on the buffer, so that the consumer cannot access the buffer until producer completes its operation.
• After performing the insert operation, the lock is released and the value of full is incremented because the producer has just filled a slot in the buffer.

The Consumer Operation

The pseudocode for the consumer function looks like this:

• The consumer waits until there is atleast one full slot in the buffer.
• Then it decrements the full semaphore because the number of occupied slots will be decreased by one, after the consumer completes its operation.
• After that, the consumer acquires lock on the buffer.
• Following that, the consumer completes the removal operation so that the data from one of the full slots is removed.
• Then, the consumer releases the lock.
• Finally, the empty semaphore is incremented by 1, because the consumer has just removed data from an occupied slot, thus making it empty.
• ← Prev
• Next →

  OS MCQ Tests

  gate mcq tests.

AfterAcademy

The producer-consumer problem in operating system.

In the previous blogs, we have learned about process synchronization and we have also seen how to achieve the process synchronization by using semaphores. In this blog, we will learn about the Producer-Consumer problem which is used for multi-process synchronization.

If you have no idea about the process synchronization, then learn from here . Also, learn about semaphore from here . Now, you are done with the prerequisites of the blog, so let's get started with the producer-consumer problem.

About Producer-Consumer problem

The Producer-Consumer problem is a classic problem this is used for multi-process synchronization i.e. synchronization between more than one processes.

In the producer-consumer problem, there is one Producer that is producing something and there is one Consumer that is consuming the products produced by the Producer. The producers and consumers share the same memory buffer that is of fixed-size.

The job of the Producer is to generate the data, put it into the buffer, and again start generating data. While the job of the Consumer is to consume the data from the buffer.

What's the problem here?

The following are the problems that might occur in the Producer-Consumer:

• The producer should produce data only when the buffer is not full. If the buffer is full, then the producer shouldn't be allowed to put any data into the buffer.
• The consumer should consume data only when the buffer is not empty. If the buffer is empty, then the consumer shouldn't be allowed to take any data from the buffer.
• The producer and consumer should not access the buffer at the same time.

What's the solution?

The above three problems can be solved with the help of semaphores(learn more about semaphores from here ).

In the producer-consumer problem, we use three semaphore variables:

• Semaphore S: This semaphore variable is used to achieve mutual exclusion between processes. By using this variable, either Producer or Consumer will be allowed to use or access the shared buffer at a particular time. This variable is set to 1 initially.
• Semaphore E: This semaphore variable is used to define the empty space in the buffer. Initially, it is set to the whole space of the buffer i.e. "n" because the buffer is initially empty.
• Semaphore F: This semaphore variable is used to define the space that is filled by the producer. Initially, it is set to "0" because there is no space filled by the producer initially.

By using the above three semaphore variables and by using the wait() and signal() function, we can solve our problem(the wait() function decreases the semaphore variable by 1 and the signal() function increases the semaphore variable by 1). So. let's see how.

The following is the pseudo-code for the producer:

The above code can be summarized as:

• while() is used to produce data, again and again, if it wishes to produce, again and again.
• produce() function is called to produce data by the producer.
• wait(E) will reduce the value of the semaphore variable "E" by one i.e. when the producer produces something then there is a decrease in the value of the empty space in the buffer. If the buffer is full i.e. the vale of the semaphore variable "E" is "0", then the program will stop its execution and no production will be done.
• wait(S) is used to set the semaphore variable "S" to "0" so that no other process can enter into the critical section.
• append() function is used to append the newly produced data in the buffer.
• signal(s) is used to set the semaphore variable "S" to "1" so that other processes can come into the critical section now because the production is done and the append operation is also done.
• signal(F) is used to increase the semaphore variable "F" by one because after adding the data into the buffer, one space is filled in the buffer and the variable "F" must be updated.

This is how we solve the produce part of the producer-consumer problem. Now, let's see the consumer solution. The following is the code for the consumer:

• while() is used to consume data, again and again, if it wishes to consume, again and again.
• wait(F) is used to decrease the semaphore variable "F" by one because if some data is consumed by the consumer then the variable "F" must be decreased by one.
• take() function is used to take the data from the buffer by the consumer.
• signal(S) is used to set the semaphore variable "S" to "1" so that other processes can come into the critical section now because the consumption is done and the take operation is also done.
• signal(E) is used to increase the semaphore variable "E" by one because after taking the data from the buffer, one space is freed from the buffer and the variable "E" must be increased.
• use() is a function that is used to use the data taken from the buffer by the process to do some operation.

So, this is how we can solve the producer-consumer problem. Hope you learned something new today.

That's it for this blog.

Do share this blog with your friends to spread the knowledge. Visit our YouTube channel for more content. You can read more blogs from here .

Keep Learning :)

Team AfterAcademy!

Recommended for You

What is Banker’s algorithm?

In this blog, we will see one of the deadlock avoidance methods i.e. Banker's Algorithm. In this algorithm, we will discuss that if we are given the number of resources available and the number of resources required by the process then we can tell that if the system will go in deadlock or not. We will understand this concept with the help of an example.

What is Fragmentation and what are its types?

In this blog, we will learn about the fragmentation problem that occurs during memory allocation. We will also study the types of fragmentation i.e. internal fragmentation and external fragmentation.

What are demand-paging and pre-paging?

In this blog, we will learn how pages are brought into the main memory in virtual memory systems. We will see two ways of doing this i.e. demand paging and pre-paging.

What is the difference between logical and physical address wrt Operating System?

In this blog, we will learn about the two types of addresses that are used for memory in the operating system. Further, we will discuss the difference among these types of memories i.e. logical memory and physical memory.

What is View in SQL?

In this blog, we will learn about the view or virtual tables in SQL. We will also discuss various operations we can perform on views in SQL.

What is a Network Operating System?

In this blog, we'll learn about the Network Operating System and its various features. We'll also see the types of Network Operating System, their advantages, and disadvantages.

Connect With Your Mentors

Janishar Ali

Amit Shekhar

20 Producer-Consumer Problem Interview Questions and Answers

Get ready for your interview with these Producer-Consumer Problem interview questions and answers to help you stand out from the competition.

The Producer-Consumer Problem is a classic example of a multi-threaded application. It is a problem that has been around for decades and is still widely used in computer science today. If you are applying for a job in software development, you may be asked questions related to the Producer-Consumer Problem during your interview. Understanding the key concepts and common questions related to this problem can help you prepare for your interview and demonstrate your knowledge. In this article, we discuss some of the most common questions related to the Producer-Consumer Problem.

Producer-Consumer Problem Interview Questions and Answers

Here are 20 commonly asked Producer-Consumer Problem interview questions and answers to prepare you for your interview:

1. What is the Producer-Consumer problem?

The Producer-Consumer problem is a classic example of a multi-process synchronization problem. It involves two processes, the producer and the consumer, which share a common buffer or queue for communication. The producer produces items that are placed in the shared buffer, while the consumer consumes them from the same buffer. The goal of the problem is to ensure that the producer does not produce more items than the consumer can consume, and vice versa. This requires proper synchronization between the two processes so that they do not interfere with each other’s operations. To achieve this, various techniques such as semaphores, monitors, and message passing have been used.

2. Can you give me some examples of real-world applications that use this pattern?

The Producer-Consumer pattern is a common design pattern used in software engineering. It can be found in many real-world applications, such as message queues and databases. For example, when an application needs to send messages between two different components, it may use a message queue that implements the Producer-Consumer pattern. The producer component will add messages to the queue, while the consumer component will take them off the queue and process them.

Another example of this pattern is in database systems. When multiple users are accessing the same data, the system must ensure that each user gets the most up-to-date version of the data. To do this, the system uses the Producer-Consumer pattern to manage access to the data. The producer component adds new versions of the data to the queue, while the consumer component takes the oldest version from the queue and updates the database with it.

3. Is it possible to write a multi-threaded program without using locks or semaphores? If yes, then how?

Yes, it is possible to write a multi-threaded program without using locks or semaphores. This can be done by using message passing between threads instead of shared memory. Message passing involves sending messages from one thread to another in order to communicate information and coordinate activities. Each thread has its own private queue for incoming messages, which allows them to process the messages in their own time.

The advantage of this approach is that there is no need for synchronization mechanisms such as locks or semaphores. Instead, each thread can simply wait until it receives a message before processing it. This eliminates the possibility of race conditions and deadlocks, since only one thread will ever have access to any given piece of data at any given time.

Another benefit of message passing is that it allows for more flexible communication patterns than traditional locking mechanisms. For example, multiple threads can send messages to each other simultaneously, allowing for greater parallelism and better performance. Additionally, message passing makes it easier to debug programs since all communication is explicit and visible.

4. How do we prevent a race condition in producer-consumer code?

In order to prevent a race condition in producer-consumer code, it is important to ensure that the shared resources are properly synchronized. This can be done by using synchronization primitives such as semaphores and mutexes. Semaphores allow multiple threads to access a shared resource while ensuring that only one thread has exclusive access at any given time. Mutexes also provide exclusive access to a shared resource but they do not allow multiple threads to access the same resource simultaneously. By using these synchronization primitives, we can guarantee that the producer and consumer threads will not interfere with each other when accessing the shared resource. Additionally, it is important to use proper locking mechanisms to ensure that the critical sections of the code are executed atomically. This ensures that no two threads can enter the critical section at the same time, thus preventing any potential race conditions.

5. How does a mutex work? Can you explain its implementation?

A mutex is a synchronization mechanism used to ensure that only one thread can access a shared resource at any given time. It works by allowing the first thread to acquire the lock, and then blocking all other threads from accessing the same resource until the lock is released. The implementation of a mutex involves two main operations: locking and unlocking.

When a thread attempts to acquire a lock on a mutex, it will check if the lock is available. If the lock is not available, the thread will be blocked until the lock becomes available. Once the lock is acquired, the thread can proceed with its task. When the thread has finished its task, it must release the lock so that other threads may use the resource.

The implementation of a mutex also requires some form of signaling between threads. This allows threads to communicate when they are waiting for the lock to become available. For example, a thread might signal another thread that it is done using the resource, or that it needs to wait for the lock to become available. This ensures that no thread is left waiting indefinitely.

6. What happens when a consumer thread tries to remove an item from an empty buffer?

When a consumer thread attempts to remove an item from an empty buffer, it will be blocked until the producer thread adds an item to the buffer. This is because the consumer thread cannot access any items in the buffer if there are none available. The consumer thread must wait for the producer thread to add an item before it can proceed with its task. In some cases, the consumer thread may also throw an exception or return an error code indicating that the buffer was empty when the attempt to remove an item was made.

7. What are the different ways of implementing a bounded buffer?

There are several ways to implement a bounded buffer, which is a type of Producer-Consumer Problem. The most common way is through the use of semaphores. Semaphores are used to control access to shared resources and can be used to limit the number of items that can be stored in the buffer at any given time. Another way to implement a bounded buffer is by using locks. Locks allow only one thread to access the buffer at a time, ensuring that no more than the maximum number of items can be stored in the buffer. Finally, another way to implement a bounded buffer is through the use of monitors. Monitors provide synchronization between threads and ensure that only one thread can access the buffer at a time. This ensures that the maximum number of items can be stored in the buffer without exceeding its capacity.

8. How would you implement a queue using only two stacks?

The Producer-Consumer Problem can be solved by implementing a queue using two stacks. This approach is known as the Two Stack Queue, and it involves creating two separate stacks to store data in a FIFO (First In First Out) order. The first stack will act as the producer, while the second stack will act as the consumer.

To implement this solution, we must first create two empty stacks. We then push items onto the producer stack until it is full. When the producer stack is full, we pop all of its elements off and push them onto the consumer stack. At this point, the consumer stack contains all of the elements from the producer stack in reverse order. To retrieve an item from the queue, we simply pop the top element off the consumer stack.

This approach allows us to maintain a FIFO ordering of elements without having to use additional memory or complex algorithms. It also ensures that the time complexity for enqueue and dequeue operations remains constant, regardless of the size of the queue.

9. What’s the difference between busy waiting and blocking on a lock? Which one is preferred in certain situations?

Busy waiting is a technique used in concurrent programming where a thread continuously checks for the availability of a resource, such as a lock. This can be done by looping until the resource becomes available or by using an atomic instruction to check if the resource is available. Busy waiting is not preferred because it wastes CPU cycles and can lead to performance issues.

Blocking on a lock is a technique used in concurrent programming where a thread waits for a resource to become available before continuing execution. The thread will wait until the resource is released, at which point it will acquire the resource and continue execution. Blocking on a lock is preferred over busy waiting because it does not waste CPU cycles and allows other threads to use the resources while the current thread is blocked.

10. What can happen if a deadlock occurs while running multiple producer-consumer threads?

If a deadlock occurs while running multiple producer-consumer threads, it can cause the entire system to become unresponsive. This is because when a deadlock occurs, two or more threads are waiting for each other to finish their tasks before they can continue. As a result, none of the threads can make any progress and the system will remain in this state until the deadlock is resolved. In some cases, the only way to resolve the deadlock is to restart the application. If left unresolved, the deadlock could lead to data loss or corruption as well as decreased performance due to the lack of resources available to the system.

11. What are the differences between a spinlock and a mutex?

A spinlock and a mutex are both synchronization mechanisms used to protect shared resources from concurrent access. The main difference between the two is that a spinlock will continuously loop until it can acquire the lock, while a mutex will block the thread until the lock is acquired.

A spinlock is typically used when the wait time for acquiring the lock is expected to be short. This type of lock is also more efficient than a mutex because it does not require context switching or kernel calls. However, if the wait time is longer than expected, then the spinning process can consume CPU cycles unnecessarily.

On the other hand, a mutex is better suited for situations where the wait time for acquiring the lock is expected to be long. A mutex will block the thread until the lock is acquired, which prevents unnecessary CPU usage. Additionally, since a mutex requires a kernel call, it is slower than a spinlock.

12. Why should we avoid polling whenever possible?

Polling should be avoided whenever possible because it can lead to inefficient use of resources. Polling requires the consumer to continuously check for new data, which can cause unnecessary strain on system resources and slow down overall performance. Additionally, polling is not a reliable way to detect when new data is available, as there may be delays in detecting new data due to network latency or other factors. Finally, polling can also lead to race conditions if multiple consumers are attempting to access the same data at the same time.

13. How can we detect potential deadlocks in our code?

Deadlocks can be detected in code by using a deadlock detection algorithm. This algorithm works by examining the state of each thread and resource to determine if any threads are waiting for resources that will never become available. If this is the case, then a deadlock has occurred. Additionally, it is possible to detect potential deadlocks before they occur by analyzing the code for patterns that could lead to deadlocks. For example, if two threads both require exclusive access to the same resource, then there is a high likelihood of a deadlock occurring. By identifying these patterns ahead of time, developers can take steps to prevent deadlocks from occurring.

14. When would you want to use a Condition object instead of Lock objects?

A Condition object is a synchronization mechanism that allows threads to wait for certain conditions to be met before continuing. It can be used instead of Lock objects when the thread needs to wait until a specific condition is satisfied, such as waiting for an item to become available in a queue or waiting for a signal from another thread. A Condition object also provides more flexibility than a Lock object because it allows multiple threads to wait on different conditions and have them signaled separately. This makes it easier to manage complex synchronization scenarios where multiple threads are waiting on different conditions.

15. What are some best practices for writing safe concurrent code?

When writing concurrent code, it is important to ensure that the code is safe and free from race conditions. One of the best practices for writing safe concurrent code is to use synchronization primitives such as locks or semaphores. These primitives can be used to protect shared resources by ensuring that only one thread has access to them at a given time. Additionally, using atomic operations can help prevent data races by ensuring that all operations on a particular variable are completed before any other threads can access it.

Another best practice for writing safe concurrent code is to avoid deadlocks. Deadlocks occur when two or more threads are waiting for each other to finish an operation before they can continue. To avoid this, developers should use techniques such as lock ordering or timeout-based locking. Finally, it is important to test concurrent code thoroughly in order to identify potential issues before they become problems. This includes testing with multiple threads running concurrently and validating the results of each thread’s execution.

16. What are the main challenges faced by developers when working with multithreaded programs?

Developers working with multithreaded programs face a number of challenges. One of the main challenges is ensuring that threads are synchronized correctly, so that they can work together without interfering with each other’s operations. This requires careful planning and design to ensure that all threads have access to shared resources in an orderly fashion. Additionally, developers must be aware of potential race conditions, which occur when two or more threads attempt to access the same resource at the same time.

Another challenge faced by developers is managing memory usage. Multithreaded programs require additional memory for thread stacks, synchronization objects, and other data structures. If not managed properly, this can lead to excessive memory consumption and poor performance. Finally, debugging multithreaded programs can be difficult due to the complexity of the code and the difficulty of reproducing errors. Developers must use specialized tools and techniques to identify and fix issues related to concurrency.

17. What do you understand about starvation? How can we resolve it?

Starvation is a situation in which a consumer thread is unable to access the shared resource it needs due to other threads consuming all of the resources. This can lead to an indefinite wait for the consumer, resulting in wasted time and resources.

In order to resolve starvation, we must ensure that each thread has equal access to the shared resource. One way to do this is by implementing a priority-based scheduling algorithm. This will allow us to assign higher priority to certain threads, ensuring that they have access to the resources before lower priority threads. Additionally, we can use synchronization techniques such as semaphores or monitors to limit the number of threads accessing the shared resource at any given time. This will help prevent one thread from monopolizing the resource and starving out other threads.

18. How can we improve the performance of a concurrent system?

Improving the performance of a concurrent system can be achieved through several methods. Firstly, it is important to ensure that the system is designed in such a way that it minimizes contention between threads. This can be done by using techniques such as lock-free data structures and thread pools. Additionally, it is beneficial to use asynchronous communication mechanisms such as message queues or event-driven architectures to reduce the amount of time spent waiting for responses from other components.

Another way to improve the performance of a concurrent system is to optimize the code used within the system. This includes ensuring that the code is well written and optimized for parallelism, making sure that any shared resources are properly synchronized, and minimizing the number of context switches between threads. Furthermore, it is also important to consider the hardware architecture when designing a concurrent system, as this can have an impact on its overall performance. Finally, caching strategies should be employed where possible to reduce the amount of time spent accessing data from external sources.

19. What do you know about the ABA problem? How can we overcome it?

The ABA problem is a classic example of the Producer-Consumer Problem. It occurs when two producers produce items that are consumed by one consumer, and the order in which the items are produced affects the outcome of the process. For example, if producer A produces item 1 followed by item 2, but then producer B produces item 2 before item 1, the consumer will receive item 2 first, resulting in an incorrect result.

To overcome this issue, we must ensure that the order of production is maintained throughout the entire process. This can be done through synchronization techniques such as locks or semaphores. These techniques allow us to control access to shared resources so that only one thread can access them at any given time. By using these techniques, we can guarantee that the order of production is maintained and the correct result is achieved.

20. How does a ReadWriteLock differ from a normal ReentrantLock?

A ReadWriteLock is a type of ReentrantLock that allows multiple threads to read from the same resource, while only allowing one thread to write to it. This ensures that any changes made by the writing thread are visible to all other readers. The main difference between a ReadWriteLock and a normal ReentrantLock is that with a ReadWriteLock, multiple threads can access the same resource for reading purposes without blocking each other. With a ReentrantLock, however, only one thread can access the resource at a time, regardless of whether they are reading or writing.

Additionally, when using a ReadWriteLock, there is an additional overhead associated with acquiring and releasing locks as compared to a ReentrantLock. This is because the ReadWriteLock must keep track of which threads have acquired read locks and which threads have acquired write locks in order to ensure that no two threads are accessing the same resource simultaneously.

20 NeoLoad Interview Questions and Answers

25 1st grade teacher interview questions and answers, you may also be interested in..., 20 azure firewall interview questions and answers, 25 customs officer interview questions and answers, 20 salesforce trigger interview questions and answers, 20 alorica interview questions and answers.

• Trending Now
• Foundational Courses
• Data Science
• Practice Problem
• Machine Learning
• System Design
• DevOps Tutorial

In this video, we will be discussing what is producer consumer problem in operating systems.

What is Producer Consumer Problem

The Producer Consumer problem is a process synchronization problem. In this problem, there is a memory buffer of a fixed size. Two processes access the shared buffer: Producer and Consumer. A producer creates new items and adds to the buffer, while a consumer picks items from the shared buffer. The problem is to ensure synchronization between the producer and the consumer such that while the producer is adding an item to the buffer, the consumer does not start accessing it.

Further, the producer should not try to add items to the buffer when it is full and the consumer should not access the buffer when it is empty. If the producer finds the buffer full, it should either sleep or discard the new item until the consumer frees a location in the buffer.

Similarly, a consumer may go to sleep if it finds the buffer empty. When the producer adds an item, the consumer can continue retrieving the data.

The Producer-Consumer problem is also known as the Bounded Buffer problem.

A solution is required for the Producer-Consumer problem such that both processes can perform their tasks without ending up in a deadlock.

Let's watch the video to understand what solution is required for producer-consumer problem.

Producer consumer problem: https://www.geeksforgeeks.org/producer-consumer-problem-using-semaphores-set-1/