copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.

com

CHAPTER - 6

In multitasking environments it is often necessary to coordinate synchroniozation between tasks.

Concurrent processes or threads very often need to read, update, or use a system-wide resource. The
appropriate coordination of access to resources such as memory, files and communications must be
managed by the application. If tasks were allowed to randomly access shared resources, corruption could
result. It is therefore necessary for an operating system to provide mechanisms for the orderly use of
shared resources. Additionally, synchronization APIs may be used to coordinate related event and timing
aspects of executing process or thread. Shared resources and event notification are the most compelling
reasons for synchronization implementation.
This chapter provides an in- depth discussion of synchronization. It explores specific
implementations of the technology. The most popular mechanism to perform synchronization is the
semaphore, so semaphores are given a great deal of coverage in this chapter.

UNDERSTANDING AND USING SEMAPHORES

Semaphores are the most popular mechanism for coordinating access between tasks. A semaphore and its
functions are used to synchronize access of shared data or resources. A general semaphore mechanism is
the basis for all of the synchronization methods employed by our platforms.
Each operating system provides general synchronization semaphore operations,while many
provide more advanced features and functionality. Windows NT and OS/2 provide the most full-featured
function sets, while NetWare and UnixWare provide a more elementary set of operations. With each
operating system, however the application developer has full and equal control over the synchronization
of tasks. With the proper programming practices, application developers can manage process coordination
in many ways.
Semaphore were introduced in 1965 by E.W Dijkstra. He suggested using a single variable to
count each process requesting access to a shared region or resource. This variable is the controlling acces
to the shared resource and is maintained by incrementing or decrementing its value:
 A value less than 0 indicates that process are waiting for the shared resource or region.
 A value greater than 0 indicates that the resource is available.

P() and V() Operation on Semaphores

Dijkstra suggested having two operations on the semaphore,p() and v() respectively . the p() operation
decrements the semaphore value by 1, while v() increments the semaphore by 1. in Dijkstra’s orginal
model, if the p() operation caused the Semaphore to go to 0,the process would spin –wait for the
semaphore value to be incremented with another v() operation. This caused the requesting process to wait
for completion of the region by another process. The busy wait-condition,however,was very inefficient in
a multitasking environment.By extending the orginal model to allow the semaphore to become negative
and thus queue up multiple waiting process, the semaphore becomes more useful.

If during p() operation the semaphore value becomes negative,the calling process is blocked.
Processes that become blocked from the p() operation are then queued for wakeup.any semaphore with a
value less than 0 signifies that process are waiting.If as a result of a p() operation the semaphore value is
still > =0, the process is allowed access to the region.
The V() operation increments the semaphore value by 1. If after the operation no processes are
queued for wakeup ( that is, the semaphore is >= 1), execution continues. If the semaphore value
remains<=0, one process is taken from the waiting ( wakeup) queue and rescheduled. The rescheduling
mechanism is system-dependent. (Each semaphore operation must be a non- interruptable, atomic action.)
The operating system must enforce the entire semaphore operation P(), or else V() will completer before
the task may be swapped. This will avoid leaving a semaphore in an incorrect state. Using semaphores,
we can solve the critical sections problems discussed in Chapter 5 (see “Critical Section: Updating and
copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com
copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com

Accessing Shared Data” in chapter 5). Listing 6.1 shows the critical sections problems encountered
earlier in Listing 5.2

LISTING 6.1

LONG stockQuote;
Main(){
Begin(TaskA);
Begin (TaskB);
}
TaskA() {
………..
stockQuote = 29.875;
totalValue = numShares * stockQuote;
………
}
TaskB() {
…….
stockQuote = 100.125;
totalValue = numShares *stockQuote;
…………
}

LISTING 6.1: Task A and B code fragment : The example code in Listing 6.1 show tasks A and B
with a potential critical section problem. It is possible for both tasks to be executing concurrently and
arrive with invalid and corrupted results. The variable stockQuote is defined as a shared variable and
updated by both tasks. If each task is not allowed to execute its two instructions uninterrupted, corruption
may result.

As shown in Listing 6.2, using a semaphore will very easily alleviate this critical section problem.

LISTING 6.2
LONG stockQuote, totalValue, numShares;
Semaphore mutex = 1;
Main() {
Begin(TaskA);
Begin(TaskB);
}
TaskA() {
………
p(&mutex);
stockQuote = 29.875;
totalValue = numShares * stockQuote;
V(&mutex);
……….
}
TaskB() {
………..
p(&mutex);
stockQuote = 100.125;
totalValue = numShates * stockQuote;
V(&mutex);
copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com
copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com

…………
}

Listing 6.2: Task code fragment with Dijkstra semaphores The very minor changes to the example in
Listing 6.2 illustrate the power of semaphores. In the updated example, a semaphore definition and
associated P() and V() operations were added. These operations will control access to the stockQuote
variable. The example starts with a variable named mutex of type semaphore being created and initialized
to 1. Assuem TaskA() and TaskB() are created as before, with TaskA() running first.

As TaskA() begins to run, the P(&mutex) instruction isexecuted. The semaphore mutex is
decremented and the value becomes 0. since the semaphore is >=0, execution continues. At this point, the
critical region has been entered and concurrent acces fo StockQuote will be denied. If TaskA executes the
stockQuote = 29.875 command and loses control of the processor, TaskB will begin. Its forst operation,
P(&mutex), will cause the semaphore mutex to be decreased by one. At this point, mutex ( urrenty0) will
be decremented and will equal-1. Since the semaphore value is less than 0, TaskB will be placed on a
witing queue for the emaphore to be released.TaskA will receive control and continue executing by
calculating the totalValue=numShares * stockQuote and signaling the semaphore to be incremented and
will evaluate to 0. This will also cause TaskB to be released from the waiting queue and be rescheduled.
Upon execution, TaskB will perform its instructions, signal the semaphore with V(), and continue
processing. In this modified example, notice that there is o way for stockQuote to be used inadvertently.
Today’s operating systems have many and varied semaphore interfaces. Each operating systems
implements semaphores in a unique manner, but all solve the same problems. Semaphores may be used to
solve synchronization of resources constraints, mutual exclusion and critical sections, and as a form of
interprocess communications. Traditional semaphore concepts and definitions have expanded by
computer scientists and implemented in various operating systems.

SEMPHORE IMPEMENTIONS

Although semaphores are a core requirement of any operating system, they are subject to varying
implementations from platform to platform. All APIs for creation, use, and release of semaphores vary
between evaluated platform but follow traditional Dijkstra semaphores as a base for implemention.
Semaphores are very flexible and may be used differently for mutual exclusion and coordination of
events.Each operating system provides basic semaphore operations for mutual exclusion; some provide a
richer set of functions for extended semaphore operations.
OS/2 and windows NT provide the most extensive set of operations, while UnixWare provides
power and control through a core set of three functions. NetWare semaphores are very basic yet provide
all the necessary functions to be extended into more specific areas. Windows NT and OS/2, for instance,
provide extended operations specifically to deal with synchronization of event within programs. NetWare
and UnixWare require the developer to use base functions to achieve the same result.
In addition, with OS/2 and Windows NT, naming of semaphores is introduced. Traditionally, a
semaphore is created, and subsequent access to that semaphore is made by sharing it via shared memory
or by transferring it via an interprocess communications mechanism to another process. With OS/2 and
NT, applications may request access to a semaphore via a logical name. At creation time, a name is
associated with a system- wide semaphore. In such environments, the operating system manages these
logical names and provides APIs for subsequent processes or threads to open a handle to these
semaphore. Often this mechanism is a much more elegant solution for semaphores.

NOVELL NETWARE

Using semaphores with NetWare 3 and 4 is extremely simple. Novell implements two classes of
semaphore functions, local and network.

copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com

copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com

 Local semaphores are used for synchronization and mutual exclusion by programs running on
NetWare servers as NLMs.
 Network semaphores are a mechanism by which a semaphore may be used by many different
computers throughout a netwoek.
When to use local and network semaphores Local semaphores are an extremely efficient operating
system mechanism, while network semaphores involve much more overhead and possibly network
transmissions. Network semaphores should only be used to coordinate activity between many systems.
Local semaphores should be used to coordinate threads running at the server. They are used for the
majority of applications running on NetWare and are tightly modeled on the Dijkstra specification of
1965/. These functions may be used to corordinate access to critical regions or other functions.
By default, all semaphores are shared and unnamed. There is no native support for named
semaphores in NetWare, although one could easily be developed. (Refer to Chapter 10 for an example of
naed semaphores on NetWare.) Each thread requesting access to the semaphores needs to obtain a
handle. This may be a global variable, an exported vaiable, or one obtained through some interprocess
communicatin mechanism.

MICROSOFT NT

Windows NT has a very extensive set of synchronization options. These options are provide by Microsoft
in the form of synchronization objects and can be used to synchronize events between processes or
threads. There are four main synchronization objects with WindowsNT:
Multex
Semaphore
Event
Critical Section

Each of these objects performs similar functions in synchronization.

Windows NT semaphores objects may be named or unnamed. When using named semaphores,
access is based on a name parameter. When using unnamed semaphores, open semaphores handles must
be passed to other threads and processes. These threads would then issue the DuplicateHandle() function
to attain access. This mechanism is described in further detail in subsequent examples.

IBM OS/2

OS/2 has the most extensive mechanism for semaphores of all the platforms. In OS/2, there are three
types of semaphores:

SEMAPHORETYPE USE
Multex Used as classical P() and V()semaphores to
coordinate access to critical regions.

Event Used as a signaling control for activities

among multiple processes. Events are
normally used to signal other processes that
some activity (event) has occurred.

Muxwait Used to allow process or thread to wait on

copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com
copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com

multiple semaphores at once

Sharable and private semaphores In OS/2, semaphores can be created that are either sharable or
provate. Sharable semaphores may be used between threads of the same or the different processes.
Private semaphores may only be used by threads within a process. In fact, IBM recommends the use of
private semaphores in the same process for performance reasons.

Named and unnamed semaphores OS/2 alsoprovides a named semaphores mechanism. This will allow
any process wit the knowledge of the semaphores ( knowing its name) to access it. Named semaphores
are by definition public semaphores. To share unnamed semaphores between processes, a handle must be
provided. The naming convention used in named semaphores is file- system- centric and must be of the
form \sem32\name.
Using semaphores with OS/2 is very straightforward. One process is required to create
semaphores and release access information to o0ther processes or threads. This may be done through a
named semaphore or a handle mechanism (unnamed semaphores). Each subsequent process or thread is
required to open the semaphores, use it, and close it. When the number of closes equals the number of
opens, the semaphores is released from the system. If the semaphore creator terminates, operations on that
semaphore are returned with error ERROR_SEM_OWNER_DIED.

copyright unnikrishnan c lecturer dcse raset emaild:-cnunnikrishnan@gmail.com