0% found this document useful (0 votes)
61 views2 pages

Understanding Race Conditions in Processes

This document describes a race condition that can occur with a print spooler system that uses shared variables to track file slots. Process A and Process B both read the shared "in" variable to determine the next free slot, but an interrupt causes Process B to run first and overwrite the slot that Process A intended to use. As a result, the file written by Process B is lost. Race conditions can cause unexpected behavior when processes access shared data without synchronization and the order of operations is non-deterministic.

Uploaded by

I S
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
61 views2 pages

Understanding Race Conditions in Processes

This document describes a race condition that can occur with a print spooler system that uses shared variables to track file slots. Process A and Process B both read the shared "in" variable to determine the next free slot, but an interrupt causes Process B to run first and overwrite the slot that Process A intended to use. As a result, the file written by Process B is lost. Race conditions can cause unexpected behavior when processes access shared data without synchronization and the order of operations is non-deterministic.

Uploaded by

I S
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

The situation where two or more processes reading or writing some share data and

the final results depends on who runs precisely when are called RACE CONDITIONS.

Let's take an Example:

A print spooler: When a process wants to print a file it enters the filename in a special

spooler directly. Another process, the Printer Daemon, periodically checks to see if

there are any files to be printed, and if there are, it prints them and removes their

name from the directory. Imagine that our spooler directory has a large number of

slots, numbered 0,1,2,..... each one capable of holding a filename. also imagine that

there are two shared variables,

out : points to next file to printed.

in : points to next free slot in the directory.

slots 0 to 3 files already printed.

slots 4 to 6 files names which has to be printed.


Now the main issue comes:

Process A reads in and store the value, 7, in a local variable called next-free-

slot. Just then a clock interrupt occurs and the CPU decides that process A

has Run long enough, it switches to process B.

Process B also reads in, and also gets a 7, so it stores the name of its in slot

7 and update into be an 8. Then it goes off and does other things.

Eventually, process A once again, starting from the place at left off last time.

It looks next free slot, finds a7 there, and writes its file name 7 in slot 7,

erasing the name that process B just put there. Then it computes next-free-

slot+1 , which is 8, and sets in to 8.

The spooler directory is now internally consistent, so the printer daemon will

not notice anything wrong, but process B will never receive any output.

You might also like