Semaphores “consist of the following elements: current value of the semaphore, process

ID of the last process to operate on the semaphore, number of processes waiting for the
semaphore value to be greater than its current value, and number of processes waiting for the
semaphore value to be zero” (Stallings 285). This simply means that the semaphore is a data
structure consisting of a counter and a queue for storing task descriptors. They can provide both
competition and cooperation synchronization. Unfortunately, they can be volatile as improper
use of semaphores can cause failures in the synchronization. This is obviously a problem.

Monitors can also provide synchronization, and are sometimes considered safer than
semaphores. Monitors themselves are just abstract data types for shared data pools. Our texts
defines them as “a programming language construct that encapsulates variables, access
procedures, and initialization code within an abstract data type” (Stallings 214). Just like
semaphores, monitors can be used for both competition and cooperation synchronization. They
are considered to be better for competition synchronization than for cooperation, as monitors
face many of the same problems that semaphores do with cooperation synchronization.

Message passing is another method for providing synchronization. It is known as the

general model for concurrency, as it can model both semaphores and monitors. They work by
making tasks follow a sender-receiver method. One task sends out an “invitation’ and waits for
another to accept that message. While waiting, it stays in a suspended state. Once it is accepted
by another task, the accepted message is known as a “rendezvous”. This is known as the
“blocking send, blocking receive” combination (Stallings 235). Both processes are blocked until
the message is transmitted and received. The other two combinations are nonblocking send,
blocking receive and nonblocking send, nonblocking receive. According to our book
nonblocking send/blocking receive is the most useful, as it allows the sender to put out many
messages to many receivers without having to wait for the original receiver. Nonblocking
send/nonblocking receive just means that neither process has to wait and that they can continue
on their way while they wait for an answer (Stallings 235).