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

Producer–Consumer Problem

The video explains the Producer–Consumer problem, a classic operating-system synchronization problem involving two cooperative processes that share a fixed-size buffer and a shared count variable.

Shared buffer and normal operation

The producer creates items and places them in the buffer. The consumer removes items for processing.

The buffer is treated as a circular array of size 8, with positions 0–7. Two indices track access:

• in points to the next empty slot where the producer can place an item.
• out points to the next slot the consumer will read.

Both indices advance using modulo arithmetic, so after position 7 they wrap back to position 0.

The shared variable count records how many items are in the buffer. If count == n, the buffer is full and the producer waits. If count == 0, the buffer is empty and the consumer waits.

In a straightforward execution, the producer adds an item and increments count, while the consumer removes an item and decrements count. The shared state stays correct when the processes do not interfere with one another.

How the synchronization error occurs

The operations count = count + 1 and count = count - 1 are not necessarily atomic. A processor may perform each operation in separate steps: load count into a register, change the value, and then write it back to memory.

A problematic execution can occur as follows:

1. The buffer contains three items, so count is 3.
2. The producer adds an item, loads 3 into its register, and increments its local value to 4.
3. Before the producer writes 4 back to memory, it is preempted.
4. The consumer removes an item. It loads the still-stored value 3, decrements it to 2, and later writes 2 back.
5. The producer resumes and writes its previously calculated value, 4.
6. The consumer then resumes and writes its previously calculated value, 2.

The buffer contains three items, but count says there are only two. This is a race condition: the final shared value depends on the order in which the processes execute their operations.

The example shows that two processes can each be individually correct yet produce incorrect shared state when their updates overlap. Preemption can occur because of an interrupt, a higher-priority process, or the expiration of a time quantum. A paused process resumes from its saved execution point rather than restarting.

Main lesson and remedies

Checking whether the buffer is full or empty does not, by itself, make access to shared data safe. Shared updates such as incrementing or decrementing count must be protected from conflicting interleavings.

The instructor identifies binary semaphores, monitors, and locks as methods for preventing this kind of synchronization problem. These mechanisms are discussed in later videos.

Speakers and sources

• Varun (“Varun sir”), instructor — Gate Smashers.
• No other speakers or external sources are identified in the subtitles.