The competitive conditions in concurrent programming

The following description of competitive conditions, from the modern operating system

In some operating systems, a collaborative process may share some common stores that can read and write to each other. This common store may be in memory (probably in the kernel data structure), or it may be a shared file. The location of the shared storage area does not affect the nature of the communication and the problems it poses. To understand how interprocess communication works in practice, we consider a simple but very common example: a spool print program. When a process needs to print a file, it places the file name under a special spool directory (spooler directory). Another process (the printer daemon) periodically checks to see if a file needs to be printed and, if so, prints and deletes the file name from the directory.

Imagine that there are many slots in the spool directory, numbered 0,1,2, ..., and each slot holds a file name. Also assume that there are two shared variables: out, pointing to the next file to be printed; in, pointing to the next free slot in the directory. You can save both variables in a file that is accessible to all processes, with a length of two characters. At some point, slots No. 0 through 3rd are empty (where the files have been printed), slots 4th to 6th are occupied (where there is a file name to print that is queued). Almost at the same time, both process A and process B decide to queue up a file for printing, as shown in case 2-21.

The following conditions may occur when the Murphy rule (where any error is likely to go wrong) takes effect. The value of process a reads to in is 7, and 7 exists in a local variable next_free_slot. At this point, a clock interrupt occurs and the CPU considers that process A has been running for a long time and decides to switch to process B. Process B also reads in, and the same gets a value of 7, so that 7 exists in the local variable next_free_slot of B. At this point two processes consider the next available slot to be 7.

Process B Now continues to run, and it will have its file name in slot 7 and update the in value to 8. Then it leaves and continues to perform other operations.

Finally, process a then runs again from where it was last interrupted. It checks the variable next_free_slot and finds that its value is 7, so the print file name is stored in slot 7th, which overwrites the file name where process B exists. It then adds 1 to the Next_free_slot and the value is 8 to save 8 in. At this point, the spool directory is consistent internally, so the printer daemon cannot find any errors, but process B will never get any printouts. A situation like this is that two or more processes read and write some shared data, and the final result depends on the precise timing of the process, called the race condition (race condition). It's a headache to debug a program that contains competitive conditions. Most tests run well, but in rare cases there are strange phenomena that cannot be explained.

The competitive conditions in concurrent programming