Operating System lab

Operating system lab
Presented by:
Mehdi D. Shahabi
S. Ehsan Behehshtian
‫ترم‬‫دوم‬‫سال‬ 1396 Evoteam.ir 1

What it is all about
• Parallel
• Multithreading
• Concurrent
• Distributed

Prerequisites
• Operating system
• Java

Evaluation
• Tests
• Projects
• Homeworks
• Classworks
• Attendance(no more than one is permitted)

Java Threads
• The Thread class provides a consistent interface to the underlying
operating system’s threading architecture.
• The Runnable interface supplies the code to be executed by the
thread that’s associated with a Thread object.
• A thread receives no arguments and returns no value .

Creating Runnable
• There are two ways to create a Runnable object. The first way is to
create an anonymous class that implements Runnable:
Runnable r =new Runnable() {
• public void run() {
• // TODO Auto-generated method stub
• }
• };

Creating Runnable
• Before Java 8, this was the only way to create a runnable. Java 8
introduced the lambda expression to more conveniently create a
runnable
Runnable r = ()->System.out.println();
• a lambda expression (lambda) is an anonymous function that’s passed
to a constructor or method for subsequent execution. lambdas work
with functional interfaces (interfaces that declare single abstract
methods), such as Runnable.

Creating a thread using runnable
Thread t = new Thread(r);

Extending Thread
public class MyThread extends Thread{
public void run(){
System.out.println();
}
}
//…
MyThread mt = new MyThread();

Starting a Thread
• After creating a Thread or Thread subclass object, you start the
thread associated with this object by calling Thread’s void start()
method. This method throws java.lang.IllegalThreadStateException
when the thread was previously started and is running or when the
thread has died:
Thread mt=new MyThread();
Thread t=new Thread(r);
t.start();
mt.start();

Starting a Thread
• Calling start() results in the runtime creating the underlying thread
and scheduling it for subsequent execution in which the runnable’s
run() method is invoked.
• When execution leaves run(), the thread is destroyed and the Thread
object on which start() was called is no longer viable, which is why
calling start() results in IllegalThreadStateException.

Creating a Daemon
boolean isDaemon = args.length != 0;
Runnable r = new Runnable() {
public void run() {
Thread thd = Thread.currentThread();
while (true)
System.out.printf("%s is %salive and in %s " + "state%n",
thd.getName(), thd.isAlive() ? "" : "not ", thd.getState());
}
};

Creating a Daemon
Thread t1 = new Thread(r, "thd1");
if (isDaemon)
t1.setDaemon(true);
System.out.printf("%s is %salive and in %s state%n", t1.getName(),
t1.isAlive() ? "" : "not ", t1.getState());
Thread t2 = new Thread(r);
t2.setName("thd2");
if (isDaemon)
t2.setDaemon(true);
System.out.printf("%s is %salive and in %s state%n", t2.getName(),
t2.isAlive() ? "" : "not ", t2.getState());
t1.start();
t2.start();

Getting and Setting a Thread’s Name
• To set the name, pass it to a suitable constructor, such as
Thread(Runnable r, String name), or call Thread’s void setName(String
name) method.
Thread t1 = new Thread(r, "thread t1");
System.out.println(t1.getName()); // Output: thread t1
Thread t2 = new Thread(r);
t2.setName("thread t2");
System.out.println(t2.getName()); // Output: thread t2

Getting a Thread’s Alive Status
• You can determine if a thread is alive or dead by calling Thread’s
boolean isAlive() method.
System.out.println(t.isAlive()); // Output: false

Getting a Thread’s Execution State
• A thread has an execution state that is identified by one of the
Thread.State enum’s constants:
• NEW: A thread that has not yet started is in this state.
• RUNNABLE: A thread executing in the JVM is in this state.
• BLOCKED: A thread that is blocked waiting for a monitor lock is in this state.
(I’ll discuss monitor locks in Chapter 2.)
• WAITING: A thread that is waiting indefinitely for another thread to perform
a particular action is in this state.
• TIMED_WAITING: A thread that is waiting for another thread to perform an
action for up to a specified waiting time is in this state.

Getting a Thread’s Execution State
System.out.println(t.getState()); // Output: NEW

Getting and Setting a Thread’s Priority
• When a computer has enough processors and/or processor cores, the
computer’s operating system assigns a separate thread to each
processor or core so the threads execute simultaneously. When a
computer doesn’t have enough processors and/or cores, various
threads must wait their turns to use the shared processors/cores.
• You can identify the number of processors and/or processor cores
that are available to the JVM by calling the java.lang.Runtime class’s
int availableProcessors() method. the return value could change
during JVM execution and is never smaller than 1.

Getting and Setting a Thread’s Priority
• Thread supports priority via its int getPriority() method, which returns
the current priority, and its void setPriority(int priority) method,
which sets the priority to priority. The value passed to priority ranges
from Thread.MIN_PRIORITY to Thread.MAX_PRIORITY—
Thread.NORMAL_PRIORITY identifies the default priority.
System.out.println(t.getPriority());
t.setPriority(Thread.MIN_PRIORITY);

Critical Section
• Goal:
• solving critical section problem using Software solution.

Critical Section Problem
Each process has a critical section segment of code Process may be
changing common variables, updating table, writing file, etc. When one
process is in its critical section, no other may be executing in its critical
section
Critical-section problem is to design a protocol to solve this
Each process must ask permission to enter its critical section in entry
section, may follow critical section with exit section, the remaining code
is in its remainder section

Programs and critical sections
The part of the program (process) that is accessing and changing
shared data is called its critical section
Process 1 Code Process 2 Code Process 3 Code

Critical Section
• The general way to do that is:
do {
entry section
critical section
exit section
remainder
}}while (TRUE))

Solution to Critical-Section Problem
• Mutual Exclusion - If process Pi is executing in its critical section, then
no other processes can be executing in their critical sections
• Progress - If no process is executing in its critical section and there
exist some processes that wish to enter their critical section, then the
selection of the processes that will enter the critical section next
cannot be postponed indefinitely
• Bounded Waiting - A bound must exist on the number of times that
other processes are allowed to enter their critical sections after a
process has made a request to enter its critical section and before that
request is granted.
• Assume that each process executes at a nonzero speed
• No assumption concerning relative speed of the N processes

Techniques for Critical Section Problem :
• Software
• Peterson's Algorithm: based on busy waiting
• Semaphores: general facility provided by operating system
• based on low-level techniques such as busy waiting or hardware assistance
• Monitors: programming language technique
• Hardware
• Exclusive access to memory location
• Interrupts that can be turned off
• must have only one processor for mutual exclusion
• Test-and-Set: special machine-level instruction
• Swap: atomically swaps contents of two words

Peterson’s Solution
• Two process solution
• Assume that the LOAD and STORE instructions are atomic; that is,
cannot be interrupted.
• The two processes share two variables:
• int turn;
• Boolean flag[2]
• The variable turn indicates whose turn it is to enter the critical
section.
• The flag array is used to indicate if a process is ready to enter the
critical section. flag[i] = true implies that process Pi is ready!

Algorithm for Process Pi

implementation
public class cSection {
int turn;
boolean flag[] = new boolean[2];
int i = 0, j = 1; // CSC variables
int counter = 0;// counter for giving
processes an upper bound
int cscVar = 13;
}

implementation

implementation
• Simplest algorithm for critical section problem solution.
• Peterson algorithm satisfies the three key point of solving the critical
section problem .

Homework
• Find and implement dekker solutions for CS
Problem(deadline:96/12/18)(4 attempts) and analyze each attempt.

Semaphore
• A semaphore maintains a set of permits for restricting the number of
threads that can access a limited resource. A thread attempting to
acquire a permit when no permits are available blocks until some
other thread releases a permit.
• Semaphores whose current values can be incremented past 1 are
known as counting semaphores, whereas semaphores whose current
values can be only 0 or 1 are known as binary semaphores or
mutexes. in either case, the current value cannot be negative.

Semaphores in Java
• The java.util.concurrent.Semaphore class implements this
synchronizer and conceptualizes a semaphore as an object
maintaining a set of permits
• You initialize a semaphore by invoking the Semaphore(int permits)
constructor where permits specifies the number of available permits.
The resulting semaphore’s fairness policy is set to false (unfair).
Alternatively, you can invoke the Semaphore(int permits, boolean fair)
constructor to also set the semaphore’s fairness setting to true (fair).

semaphores and fairness
• When the fairness setting is false, Semaphore makes no guarantees
about the order in which threads acquire permits. in particular,
barging is permitted; that is, a thread invoking acquire() can be
allocated a permit ahead of a thread that has been waiting
• When fair is set to true, the semaphore guarantees that threads
invoking any of the acquire() methods are selected to obtain permits
in the order in which their invocation of those methods was
processed (first-in-first-out; FiFo).
• it’s possible for one thread to invoke acquire() before another thread
but reach the ordering point after the other thread, and similarly
upon return from the method.

Some of semaphores methods
• Semaphore also offers the following methods:
• void acquire(): Acquire a permit from this semaphore, blocking until one is
available or the calling thread is interrupted. InterruptedException is thrown
when it’s interrupted.
• void acquire(int permits): Acquire permits from this semaphore, blocking until
they are available or the calling thread is interrupted. InterruptedException is
thrown when interrupted; IllegalArgumentException is thrown when permits
is less than zero.
• void acquireUninterruptibly(): Acquire a permit, blocking until one is
available.
• void acquireUninterruptibly(int permits): Acquire permits permits, blocking
until they are all available. IllegalArgumentException is thrown when permits
is less than zero.

Some of semaphores methods
• void release(): Release a permit, returning it to the semaphore. The
number of available permits is increased by one. If any threads are trying
to acquire a permit, one thread is selected and given the permit that was
just released. That thread is reenabled for thread scheduling purposes.
• void release(int permits): Release permits permits, returning them to the
semaphore. The number of available permits is increased by permits. If any
threads are trying to acquire permits, one is selected and given the permits
that were just released. If the number of available permits satisfies that
thread’s request, the thread is reenabled for thread scheduling purposes;
otherwise, the thread will wait until sufficient permits are available. If
there are permits available after this thread’s request has been satisfied,
those permits are assigned to other threads trying to acquire permits.
IllegalArgumentException is thrown when permits is less than zero.

Semaphore implementation
Semaphore sem = new Semaphore(N, fairness)
sem.acquire(); //wait(sem), P(sem)
sem.release(); //signal(sem), V(sem)

Exercise :
• Create a thread which has the following run method:
public void run() {
for (int i=0; i<000; i++) {
<< NON critical >>
Wait(s)
<<critical>>
Signal(s)
<<NON critical>>
}
}

Exercise :
• Semaphore and thread ID is sent through the constructor:
Thread t = new myThread(s,id)
• Set semaphore size to 4 and create 10 threads
• Replace << NON critical >> and <<critical>> with a print method
• Use Thread.sleep(int n) to wait for random time in each thread

Homework
• Research and implement other synchronizers such as:
• Countdown Latches
• Cyclic Barriers
• Phasers
• What your research document should include is what is the concept
and what are the different applications for each and how it is
implemented
• Deadline:96/12/29

Semaphore implementation
Semaphore sem = new Semaphore(N, fairness)
sem.acquire(); //wait(sem), P(sem)
sem.release(); //signal(sem), V(sem)

Exercise :
• Create a thread which has the following run method:
public void run() {
for (int i=0; i<000; i++) {
<< NON critical >>
Wait(s)
<<critical>>
Signal(s)
<<NON critical>>
}
}

Exercise :
• Semaphore and thread ID is sent through the constructor:
Thread t = new myThread(s,id)
• Set semaphore size to 4 and create 10 threads
• Replace << NON critical >> and <<critical>> with a print method
• Use Thread.sleep(int n) to wait for random time in each thread

Now Solving a CS problem using semaphores
• In the remaining time we would solve last semesters second phase so
that you can see how easy it was to solve
• After that you need to solve a problem on your own.

Cigarette smokers problem
• The cigarette smokers problem problem was originally presented by
Suhas Patil , who claimed that it cannot be solved with semaphores.
That claim comes with some qualiﬁcations, but in any case the
problem is interesting and challenging.
• Four threads are involved: an agent and three smokers
• Smoker phases:
• waiting for ingredients
• making
• smoking

• Ingredients
• Tobacco
• Paper
• Matches
• We assume that the agent has an infinite supply of all three
ingredients, and each smoker has an infinite supply of one of the
ingredients; that is, one smoker has matches, another has paper, and
the third has tobacco.
• The agent repeatedly chooses two different ingredients at random
and makes them available to the smokers. Depending on which
ingredients are chosen, the smoker with the complementary
ingredient should pick up both resources and proceed.

• For example, if the agent puts out tobacco and paper, the smoker
with the matches should pick up both ingredients, make a cigarette,
and then signal the agent.
• To explain the premise, the agent represents an operating system that
allocates resources, and the smokers represent applications that need
resources. The problem is to make sure that if resources are available
that would allow one more applications to proceed, those
applications should be woken up. Conversely, we want to avoid
waking an application if it cannot proceed.

• Based on this premise, there are three versions of this problem that
often appear in textbooks:
• The impossible version
• The interesting version
• The trivial version

The impossible version
• Patil’s version imposes restrictions on the solution. First, you are not
allowed to modify the agent code. If the agent represents an
operating system, it makes sense to assume that you don’t want to
modify it every time a new application comes along. The second
restriction is that you can’t use conditional statements or an array of
semaphores. With these constraints, the problem cannot be solved,
but as Parnas points out, the second restriction is pretty artiﬁcial [7].
With constraints like these, a lot of problems become unsolvable.

The interesting version
• This version keeps the ﬁrst restriction—you can’t change the agent
code—but it drops the others.

The trivial version
• In some textbooks, the problem speciﬁes that the agent should signal
the smoker that should go next, according to the ingredients that are
available. This version of the problem is uninteresting because it
makes the whole premise, the ingredients and the cigarettes,
irrelevant. Also, as a practical matter, it is probably not a good idea to
require the agent to know about the other threads and what they are
waiting for. Finally, this version of the problem is just too easy.

• Naturally, we will focus on the interesting version. To complete the
statement of the problem, we need to specify the agent code. The
agent uses the following semaphores:

Agent semaphores
1. agentSem = Semaphore(1)
2. tobacco = Semaphore(0)
3. paper = Semaphore(0)
4. match = Semaphore(0)

Agent code
• The agent is actually made up of three concurrent threads, Agent A,
Agent B and Agent C. Each waits on agentSem; each time agentSem is
signaled, one of the Agents wakes up and provides ingredients by
signaling two semaphores.

Agent code

Problems you may encounter
This problem is hard because the natural solution does not work. It is
tempting to write something like:
What’s wrong?

Problems you may encounter
• Deadlock
• The problem with the previous solution is the possibility of deadlock. Imagine
that the agent puts out tobacco and paper. Since the smoker with matches is
waiting on tobacco, it might be unblocked. But the smoker with tobacco is
waiting on paper, so it is possible (even likely) that it will also be unblocked.
Then the ﬁrst thread will block on paper and the second will block on match.
Deadlock!

Smokers problem hint
• The solution proposed by Parnas uses three helper threads called
“pushers” that respond to the signals from the agent, keep track of
the available ingredients, and signal the appropriate smoker. The
additional variables and semaphores are
• The boolean variables indicate whether or not an ingredient is on the
table. The pushers use tobaccoSem to signal the smoker with
tobacco, and the other semaphores likewise.

Smoker problem solution
• Here is the code for one of the pushers:

• This pusher wakes up any time there is tobacco on the table. If it finds
isPaper true, it knows that Pusher B has already run, so it can signal
the smoker with matches. Similarly, if it finds a match on the table, it
can signal the smoker with paper. But if Pusher A runs first, then it will
find both isPaper and isMatch false. It cannot signal any of the
smokers, so it sets isTobacco.
• The other pushers are similar. Since the pushers do all the real work,
the smoker code is trivial:

• Parnas presents a similar solution that assembles the boolean
variables, bitwise, into an integer, and then uses the integer as an
index into an array of semaphores. That way he can avoid using
conditionals (one of the artiﬁcial constraints). The resulting code is a
bit more concise, but its function is not as obvious.

What you need to solve in class
• Generalized Smokers Problem
• Parnas suggested that the smokers problem becomes more diﬃcult if we
modify the agent, eliminating the requirement that the agent wait after
putting out ingredients. In this case, there might be multiple instances of an
ingredient on the table.
• Puzzle: modify the previous solution to deal with this variation.

Generalized Smokers Problem Hint
• If the agents don’t wait for the smokers, ingredients might
accumulate on the table. Instead of using boolean values to keep
track of ingredients, we need integers to count them.

Generalized Smokers Problem Solution
• Here is the modiﬁed code for Pusher A:

Generalized Smokers Problem Solution
• One way to visualize this problem is to imagine that when an Agent runs, it
creates two pushers, gives each of them one ingredient, and puts them in a
room with all the other pushers. Because of the mutex, the pushers file
into a room where there are three sleeping smokers and a table. One at a
time, each pusher enters the room and checks the ingredients on the table.
If he can assemble a complete set of ingredients, he takes them off the
table and wakes the corresponding smoker. If not, he leaves his ingredient
on the table and leaves without waking anyone.
• This is an example of a pattern we will see several times, which I call a
scoreboard. The variables numPaper, numTobacco and numMatch keep
track of the state of the system. As each thread files through the mutex, it
checks the state as if looking at the scoreboard, and reacts accordingly.

HomeWork
• Solve your own specific Problem which we will put in Telegram
channel .
• Deadline:96/2/14

Race Conditions
• A race condition occurs when the correctness of a computation
depends on the relative timing or interleaving of multiple threads by
the scheduler. Consider the following code fragment, which performs
a computation as long as a certain precondition holds:
• if (a == 10.0) b = a / 2.0;
• There is no problem with this code fragment in a single-threaded
context, and there is no problem in a multithreaded context when a
and b are local variables. However, assume that a and b identify
instance or class (static) field variables and that two threads
simultaneously access this code.

Race Conditions
• Suppose that one thread has executed if (a == 10.0) and is about to
execute b = a / 2.0 when suspended by the scheduler, which resumes
another thread that changes a. Variable b will not equal 5.0 when the
former thread resumes its execution. (If a and b were local variables,
this race condition wouldn’t occur because each thread would have
its own copy of these local variables.)
• The code fragment is an example of a common type of race condition
that’s known as check-then-act, in which a potentially stale
observation is used to decide on what to do next. In the previous
code fragment, the “check” is performed by if (a == 10.0) and the
“act” is performed by b = a / 2.0;.

Race Conditions
• Another type of race condition is read-modify-write, in which new
state is derived from previous state. The previous state is read, then
modified, and finally updated to reflect the modified result via three
indivisible operations. However, the combination of these operations
isn’t indivisible.
• A common example of read-modify-write involves a variable that’s
incremented to generate a unique numeric identifier. For example, in
the following code fragment, suppose that counter is an instance field
of type int (initialized to 1) and that two threads simultaneously
access this code:

Race Conditions
• Although it might look like a single operation, expression counter++ is
actually three separate operations: read counter’s value, add 1 to this
value, and store the updated value in counter. The read value
becomes the value of the expression.
• Suppose thread 1 calls getID() and reads counter’s value, which
happens to be 1, before it’s suspended by the scheduler. Now
suppose that thread 2 runs, calls getID(), reads counter’s value (1),
adds 1 to this value, stores the result (2) in counter, and returns 1 to
the caller.
• At this point, assume that thread 2 resumes, adds 1 to the previously
read value (1), stores the result (2) in counter, and returns 1 to the
caller. Because thread 1 undoes thread 2, we have lost an increment
and a non-unique ID has been generated. This method is useless.

Data Races
• A race condition is often confused with a data race in which two or
more threads (in a single application) access the same memory
location concurrently, at least one of the accesses is for writing, and
these threads don’t coordinate their accesses to that memory. When
these conditions hold, access order is non-deterministic. Different
results may be generated from run to run, depending on that order.
Consider the following example:

Data Races
• Assume that thread 1 invokes getInstance() first. Because it observes
a null value in the parser field, thread 1 instantiates Parser and
assigns its reference to parser. When thread 2 subsequently calls
getInstance(), it could observe that parser contains a non-null
reference and simply return parser’s value. Alternatively, thread 2
could observe a null value in parser and create a new Parser object.
Because there is no happens-before ordering (one action must
precede another action) between thread 1’s write of parser and
thread 2’s read of parser (because there is no coordinated access to
parser), a data race has occurred.

Cached Variables
• To boost performance, the compiler, the Java virtual machine (JVM),
and the operating system can collaborate to cache a variable in a
register or a processor-local cache, rather than rely on main memory.
Each thread has its own copy of the variable. When one thread writes
to this variable, it’s writing to its copy; other threads are unlikely to
see the update in their copies.

Cached Variables

Cached Variables
• The class field named result demonstrates the cached variable
problem. This field is accessed by a worker thread that executes result
= computePi(50000); in a lambda context, and by the default main
thread when it executes System.out.println(result);.
• The worker thread could store computePi()’s return value in its copy
of result, whereas the default main thread could print the value of its
copy. The default main thread might not see the result =
computePi(50000); assignment and its copy would remain at the null
default. This value would output instead of result’s string
representation (the computed pi value).

Synchronizing Access to Critical Sections
• You can use synchronization to solve the previous thread problems.
Synchronization is a JVM feature that ensures that two or more concurrent
threads don’t simultaneously execute a critical section, which is a code
section that must be accessed in a serial (one thread at a time) manner.
• This property of synchronization is known as mutual exclusion because
each thread is mutually excluded from executing in a critical section when
another thread is inside the critical section. For this reason, the lock that
the thread acquires is often referred to as a mutex lock.
• Synchronization also exhibits the property of visibility in which it ensures
that a thread executing in a critical section always sees the most recent
changes to shared variables. It reads these variables from main memory on
entry to the critical section and writes their values to main memory on exit.
• Synchronization is implemented in terms of monitors, which are
concurrency constructs for controlling access to critical sections, which
must execute indivisibly. Each Java object is associated with a monitor,
which a thread can lock or unlock by acquiring and releasing the monitor’s
lock (a token).

Synchronizing Access to Critical Sections
• Note: a thread that has acquired a lock doesn’t release this lock when it
calls one of Thread’s sleep() methods.
• Only one thread can hold a monitor’s lock. Any other thread trying to lock
that monitor blocks until it can obtain the lock. When a thread exits a
critical section, it unlocks the monitor by releasing the lock. Locks are
designed to be reentrant to prevent deadlock (discussed later). When a
thread attempts to acquire a lock that it’s already holding, the request
succeeds.
• Tip: the java.lang.Thread class declares a static boolean holdsLock(Object
o) method that returns true when the calling thread holds the lock on
object o. you will find this method handy in assertion statements, such as
assert Thread.holdsLock(o);.
• Java provides the synchronized keyword to serialize thread access to a
method or a block of statements (the critical section).

Using Synchronized Methods
• A synchronized method includes the synchronized keyword in its
header. For example, you can use this keyword to synchronize the
former getID() method and overcome its read-modify-write race
condition as follows:
public synchronized int getID() {
return counter++;
}

• When synchronizing on an instance method, the lock is associated
with the object on which the method is called. For example, consider
the following ID class:
public class ID {
private int counter; // initialized to 0 by default
public synchronized int getID() {
return counter++;
}
}

• Suppose you specify the following code sequence:
ID id = new ID();
System.out.println(id.getID());
• The lock is associated with the ID object whose reference is stored in
id. If another thread called id.getID() while this method was
executing, the other thread would have to wait until the executing
thread released the lock.
• When synchronizing on a class method, the lock is associated with the
java.lang. Class object corresponding to the class whose class method
is called. For example, consider the following ID class:

• public class ID {
private static int counter; // initialized to 0 by default
public static synchronized int getID() {
return counter++;
}
}
Suppose you specify the following code sequence:
System.out.println(ID.getID());
The lock is associated with ID.class, the Class object associated with ID. If
another thread called ID.getID() while this method was executing, the other
thread would have to wait until the executing thread released the lock.

Using Synchronized Blocks
• A synchronized block of statements is prefixed by a header that
identifies the object whose lock is to be acquired. It has the following
syntax:
• synchronized(object) { /* statements */ }
• According to this syntax, object is an arbitrary object reference. The
lock is associated with this object.
• You can solve this problem with two synchronized blocks:

Runnable r = () -> {
synchronized(FOUR) {
result = computePi(50000);
}
};
// …
synchronized(FOUR) {
System.out.println(result);
}

These two blocks identify a pair of critical sections. Each block is guarded by
the same object so that only one thread can execute in one of these blocks
at a time. Each thread must acquire the lock associated with the object
referenced by constant FOUR before it can enter its critical section.
This code fragment brings up an important point about synchronized blocks
and synchronized methods. Two or more threads that access the same code
sequence must acquire the same lock or there will be no synchronization.
This implies that the same object must be accessed. In the previous example,
FOUR is specified in two places so that only one thread can be in either
critical section. If I specified synchronized(FOUR) in one place and
synchronized("ABC") in another, there would be no synchronization because
two different locks would be involved.

Beware of Liveness Problems
• The term liveness refers to something beneficial happening
eventually. A liveness failure occurs when an application reaches a
state in which it can make no further progress. In a single-threaded
application, an infinite loop would be an example. Multithreaded
applications face the additional liveness challenges of deadlock,
livelock, and starvation:

• Deadlock: Thread 1 waits for a resource that thread 2 is holding
exclusively and thread 2 is waiting for a resource that thread 1 is
holding exclusively. Neither thread can make progress.
• Livelock: Thread x keeps retrying an operation that will always fail. It
cannot make progress for this reason.
• Starvation: Thread x is continually denied (by the scheduler) access
to a needed resource in order to make progress. Perhaps the scheduler
executes higher-priority threads before lower-priority threads and
there is always a higher-priority thread available for execution.
Starvation is also commonly referred to as indefinite postponement.

• Consider deadlock. This pathological problem occurs because of too
much synchronization via the synchronized keyword. If you’re not
careful, you might encounter a situation where locks are acquired by
multiple threads, neither thread holds its own lock but holds the lock
needed by some other thread, and neither thread can enter and later
exit its critical section to release its held lock because another thread
holds the lock to that critical section. Listing 2-1’s atypical example
demonstrates this scenario.

• Listing 2-1’s thread A and thread B call instanceMethod1() and
instanceMethod2(), respectively, at different times. Consider the
following execution sequence:

• 1. Thread A calls instanceMethod1(), obtains the lock assigned to the lock1-
referenced object, and enters its outer critical section (but has not yet
acquired the lock assigned to the lock2-referenced object).
• 2. Thread B calls instanceMethod2(), obtains the lock assigned to the
lock2-referenced object, and enters its outer critical section (but has not
yet acquired the lock assigned to the lock1-referenced object).
• 3. Thread A attempts to acquire the lock associated with lock2. The JVM
forces the thread to wait outside of the inner critical section because
thread B holds that lock.
• 4. Thread B attempts to acquire the lock associated with lock1. The JVM
forces the thread to wait outside of the inner critical section because
thread A holds that lock.
• 5. Neither thread can proceed because the other thread holds the needed
lock. You have a deadlock situation and the program (at least in the context
of the two threads) freezes up.

Volatile variables

Monitor

Monitor
• void wait(): Cause the current thread to wait until another thread invokes
the notify() or notifyAll() method for this object, or for some other thread
to interrupt the current thread while waiting.
• void wait(long timeout):
• void wait(long timeout, int nanos):
• void notify():
• void notifyAll():
• The three wait() methods throw java.lang.InterruptedException when any
thread interrupted the current thread before or while the current thread
was waiting for a notification. The interrupted status of the current thread
is cleared when this exception is thrown.

Monitor
• This API leverages an object’s condition queue, which is a data
structure that stores threads waiting for a condition to exist. The
waiting threads are known as the wait set. Because the condition
queue is tightly bound to an object’s lock, all five methods must be
called from within a synchronized context (the current thread must be
the owner of the object’s monitor); otherwise,
java.lang.IllegalMonitorStateException is thrown. The following
code/pseudocode fragment demonstrates the no argument wait()
method:

Monitor
• The wait() method is called from within a synchronized block that
synchronizes on the same object as the object on which wait() is
called (obj). Because of the possibility of spurious wakeups (a thread
wakes up without being notified, interrupted, or timing out), wait() is
called from within a while loop that tests for the condition holding
and reexecutes wait() when the condition still doesn’t hold. After the
while loop exits, the condition exists and an action appropriate to the
condition can be performed.

Monitor
• Caution: never call a wait() method outside of a loop. the loop tests
the condition before and after the wait() call. testing the condition
before calling wait() ensures liveness. if this test was not present, and
if the condition held and notify() had been called prior to wait() being
called, it’s unlikely that the waiting thread would ever wake up.
retesting the condition after calling wait() ensures safety. if retesting
didn’t occur, and if the condition didn’t hold after the thread had
awakened from the wait() call (perhaps another thread called notify()
accidentally when the condition didn’t hold), the thread would
proceed to destroy the lock’s protected invariants.

Monitor
• The following code fragment demonstrates the notify() method,
which notifies the waiting thread in the previous example:
• Notice that notify() is called from a critical section guarded by the
same object (obj) as the critical section for the wait() method. Also,
notify() is called using the same obj reference. Follow this pattern and
you shouldn’t get into trouble.

Monitor
• Producer-Consumer with limited buffer:
• Two threads:
• Producer
• Consumer
• Use Semaphore
• Use Monitor and synchronized methods
• Create semaphore using monitor

Producer-Consumer

Creating Semaphore Using Monitor

Monitor
• HomeWork:
• Solve your specified problems using monitor
• Deadline:
• 97/2/21

IPC

From Coulouris, Dollimore, Kindberg and Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Slides for Chapter 5:
Remote invocation

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 5.1
Middleware layers
Applications
Middleware
layersUnderlying interprocess communication primitives:
Sockets, message passing, multicast support, overlay networks
UDP and TCP
Remote invocation, indirect communication
This chapter
(and Chapter 6)

Sockets

What you need to do?
• Write a chatroom using Sockets
• DeadLine:
• 97/3/4 23:59:59

Pipe and Filter

Example

Example
• Producer Creates Random numbers
• Filter calculates Generated numbers Mean
• Consumer Prints them

Producer
** A thread that writes random numbers to an output stream. */
class Producer extends Thread
{
/** Constructs a producer thread.
@param os the output stream */
public Producer(OutputStream os)
{
out = new DataOutputStream(os);
}
public void run()
{
while (true)
{
try
{
double num = rand.nextDouble();
out.writeDouble(num);
out.flush();
sleep(Math.abs(rand.nextInt() % 1000 ));
}
catch(Exception e)
{
System.out.println("Error: " + e);
}
}
}
private DataOutputStream out;
private Random rand = new Random();
}

Filter
/** A thread that reads numbers from a stream and writes their average to an output stream. */
class Filter extends Thread
{
/** Constructs a filter thread. 80. @param is the output stream 82. @param os the output stream 80. */
public Filter(InputStream is, OutputStream os)
{
in = new DataInputStream(is);
out = new DataOutputStream(os);
}
public void run()
{
for (;;)
{
try
{
double x = in.readDouble();
total += x;
count++;
if (count != 0) out.writeDouble(total / count);
}
catch(IOException e)
{
}
}
}
private DataInputStream in;
private DataOutputStream out;
private double total = 0;
private int count = 0;
}

Consumer
/** A thread that reads numbers from a stream and prints out those that deviate from previous inputs by a threshold value. */
class Consumer extends Thread
{
/** Constructs a consumer thread. @param is the input stream */
public Consumer(InputStream is)
{
in = new DataInputStream(is);
}
public void run()
{
for(;;)
{
try
{
double x = in.readDouble();
if (Math.abs(x - oldx) > THRESHOLD)
{
System.out.println(x);
oldx = x;
}
}
catch(IOException e)
{
}
}
}
private double oldx = 0;
private DataInputStream in;
private static final double THRESHOLD = 0.01;
}

PipedTest
import java.util.*;
import java.io.*;
/** This program demonstrates how multiple threads communicate
Producer Filter Consumer Output Pipe Input Pipe through pipes. */
public class PipeTest {
public static void main(String args []){
try{
PipedOutputStream pout1 = new PipedOutputStream();
PipedInputStream pin1 = new PipedInputStream();
PipedOutputStream pout2 = new PipedOutputStream();
PipedInputStream pin2 = new PipedInputStream();
/* construct threads */
Producer prod = new Producer(pout1);
Filter filt = new Filter(pin1, pout2);
Consumer cons = new Consumer(pin2);
/* start threads */
prod.start();
filt.start();
cons.start();
}catch (IOException e){}
}
}

What you need to do:
• Create a messenger Program
• This Program has 2 windows :
1. With send button the message will be sent
2. With enable and disable button to receive messages or not
• DeadLine:
• 97/3/4 23:59:59

RMI and RPC

Figure 5.2
Request-reply communication
Request
ServerClient
doOperation
(wait)
(continuation)
Reply
message
getRequest
execute
method
message
select object
sendReply

Figure 5.4
Request-reply message structure
messageType
requestId
remoteReference
operationId
arguments
int (0=Request, 1= Reply)
int
RemoteRef
int or Operation
array of bytes

Figure 5.5
RPC exchange protocols
R Request
RR Reply
RRA Acknowledge reply
Request
Request Reply
Client Server Client
Name Messages sent by

Figure 5.6
HTTP request message
GET //www.dcs.qmw.ac.uk/index.html HTTP/ 1.1
URL or pathnamemethod HTTP version headers message body

Figure 5.7
HTTP Reply message
HTTP/1.1 200 OK resource data
HTTP version status code reason headers message body

Figure 5.10
Role of client and server stub procedures in RPC
client
Request
Reply
CommunicationCommunication
modulemodule dispatcher
service
client stub server stub
procedure procedure
client process server process
procedureprogram

Figure 5.11
Files interface in Sun XDR

Figure 5.12
Remote and local method invocations
invocation invocation
remote
invocation
remote
local
local
local
invocation
invocation
A
B
C
D
E
F

Figure 5.13
A remote object and its remote interface
interface
remote
m1
m2
m3
m4
m5
m6
Data
implementation
remoteobject
{ of methods

Figure 5.14
Instantiation of remote objects

Figure 5.15
The role of proxy and skeleton in remote method invocation

RMI code

Server (Interface)
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface RemoteUtility extends Remote {
//remote object interface that the server and client would share
String echo(String msg) throws RemoteException;
int add(int n1,int n2)throws RemoteException;
}

Server(remote object class)
import java.rmi.server.UnicastRemoteObject;
public class RemoteutilityImpl extends UnicastRemoteObject implements
RemoteUtility{
public RemoteutilityImpl() throws RemoteException {
}
public String echo(String msg){
return msg;
}
public int add(int n1,int n2){
return n1+n2;
}
}

SERVER (SERVER)
import java.rmi.AlreadyBoundException;
import java.rmi.Remote;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class Remoterserver {
public static void main(String[] args) throws AlreadyBoundException {
try{
//creating object that we want to access remotely
RemoteutilityImpl remoteUtility=new RemoteutilityImpl();
//Creating registry on port <20>
Registry registery=LocateRegistry.createRegistry(20);
//binding the object to a name
String name="My remote utility";
registery.bind(name,remoteUtility);
System.out.println(" Remote server is ready ");
}
catch(RemoteException e){
e.printStackTrace();
}
}
}

Clientimport java.rmi.NotBoundException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
public class client {
public static void main(String[] args) throws RemoteException, NotBoundException {
//getting the registry from the network
Registry registry=LocateRegistry.getRegistry("localhost",20);
//looking for the remote object
String name="My remote utility";
RemoteUtility stub=(RemoteUtility)registry.lookup(name);
//sending the message to the remote object
String msg="Hello";
String reply=stub.echo(msg);
System.out.println("Echo Message : " + msg +" Echo reply : "+ reply);
//sending to numbers so that the remote object would add
int n1=10;
int n2=20;
int sum=stub.add(n1,n2);
System.out.println(sum);
}
}

From Coulouris, Dollimore, Kindberg and Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Slides for Chapter 9
Web Services

Figure 9.1
Web services infrastructure and components
Security
Service descriptions (in WSDL)
Applications
Directory service
Web Services
XML
Choreography
SOAP
URIs (URLs or URNs) HTTP, SMTP or other transport

hire car booking
Figure 9.2
The ‘travel agent service’ combines other web
services
hotel booking a
Travel Agent
flight booking a
hire car booking a
Service
Client
flight booking
b
hotel booking b
b

Figure 9.3
SOAP message in an envelopeenvelope
header
body
header element
body element
header element
body element

Figure 9.4
Example of a simple request without headers
m:exchange
env:envelope xmlns:env =namespace URI for SOAP envelopes
m:arg1
env:body
xmlns:m = namespace URI of the service description
Hello
m:arg2
World
In this figure and the next, each XML element is represented by a shaded
box with its name in italic followed by any attributes and its content

Figure 9.5
Example of a reply corresponding to the request in
Figure 9.4
env:envelope xmlns:env = namespace URI for SOAP envelope
m:res1
env:body
xmlns:m = namespace URI for the service description
m:res2
World
m:exchangeResponse
Hello

Figure 9.6
Use of HTTP POST Request in SOAP client-server
communication
endpoint address
action
POST /examples/stringer
Host: www.cdk4.net
Content-Type: application/soap+xml
Action: http://www.cdk4.net/examples/stringer#exchange
<env:envelope xmlns:env= namespace URI for SOAP envelope
<env:header> </env:header>
<env:body> </env:body>
</env:Envelope>
Soap
message
HTTP
header

Figure 9.10
The main elements in a WSDL description
abstract concrete
how where
definitions
types
target namespace
interface bindings servicesmessage
document style request-reply style

Figure 9.11
WSDL request and reply messages for the
newShape operation
message name = "ShapeList_newShape"
type = "ns:GraphicalObject "
part name ="GraphicalObject_1"
tns – target namespace xsd – XML schema definitions
message name = "ShapeList_newShapeResponse"
part name= "result"
type= "xsd:int"

Figure 9.12
Message exchange patterns for WSDL operations
Name
In-Out
In-Only
Robust In-Only
Out-In
Out-Only
Robust Out-Only
Client Server Delivery Fault message
Request Reply may replace Reply
Request no fault message
Request guaranteed may be sent
Reply Request may replace Reply
Request no fault message
Request guaranteed may send fault
Messages sent by

Figure 9.13
WSDL operation newShape
operation name = "newShape"
input message = tns:ShapeList_newShape
output message ="tns:ShapeList_newShapeResponse"
pattern = In-Out
tns – target namespace xsd – XML schema definitions
The names operation, pattern,input andoutput are defined in the XML schema for WSDL

Figure 9.14
SOAP binding and service definitions
soap:binding transport = URI
binding
style= "rpc"
endpoint
service
name =
binding ="tns:ShapeListBinding"
soap:address
location = service URI
name = "MyShapeListService"
name = "ShapeListPort"
for schemas for soap/http
the service URI is:
operation
soap:operation
soapAction
ShapeListBinding
tns:ShapeListtype =
name= "newShape"
input
soap:body
encoding, namespace
soap:body
encoding, namespace
output
“http://localhost:8080/ShapeList-jaxrpc/ShapeList”

Figure 9.15
The main UDDI data structures
tModel
businessServices
tModel
businessEntity
information
about the publisher
tModel
businessServiceshuman readable
service descriptions
key
key
URL
URL
URL
businessServices
information
about a
family of services
human readable
service interfaces
bindingTemplate
bindingTemplate
bindingTemplate
information
about the
key
service interfaces

Soap Code
163
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService
public interface UC
{
@WebMethod double c2f(double degrees);
@WebMethod double cm2in(double cm);
@WebMethod double f2c(double degrees);
@WebMethod double in2cm(double in);
}

Soap Code
164
import javax.jws.WebService;
@WebService(endpointInterface = "ca.javajeff.uc.UC")
public class UCImpl implements UC
{
@Override
public double c2f(double degrees)
{
return degrees * 9.0 / 5.0 + 32;
}
@Override
public double cm2in(double cm)
{
return cm / 2.54;
}
@Override
public double f2c(double degrees)
{
return (degrees - 32) * 5.0 / 9.0;
}
@Override
public double in2cm(double in)
{
return in * 2.54;
}
}

Soap Code
165
import javax.xml.ws.Endpoint;
import ca.javajeff.uc.UCImpl;
public class UCPublisher
{
public static void main(String[] args)
{
Endpoint.publish("http://localhost:9901/UC", new UCImpl());
}
}

Restful Web Service
package com.vogella.jersey.first;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
@Path("/hello")
public class Hello {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String sayPlainTextHello() {
return "Hello Jersey";
}
@GET
@Produces(MediaType.TEXT_XML)
public String sayXMLHello() {
return "<?xml version="1.0"?>" + "<hello> Hello Jersey" + "</hello>";
}
@GET
@Produces(MediaType.TEXT_HTML)
public String sayHtmlHello() {
return "<html> " + "<title>" + "Hello Jersey" + "</title>"
+ "<body><h1>" + "Hello Jersey" + "</body></h1>" + "</html> ";
}
}

Restful web services
package com.vogella.jersey.first.client;
import java.net.URI;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.WebTarget;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.UriBuilder;
import org.glassfish.jersey.client.ClientConfig;

Restful web services
public class Test {
public static void main(String[] args) {
ClientConfig config = new ClientConfig();
Client client = ClientBuilder.newClient(config);
WebTarget target = client.target(getBaseURI());
String response = target.path("rest").
path("hello").
request().
accept(MediaType.TEXT_PLAIN).
get(Response.class)
.toString();
String plainAnswer =
target.path("rest").path("hello").request().accept(MediaType.TEXT_PLAIN).get(String.class);
String xmlAnswer =
target.path("rest").path("hello").request().accept(MediaType.TEXT_XML).get(String.class);
String htmlAnswer=
target.path("rest").path("hello").request().accept(MediaType.TEXT_HTML).get(String.class);
System.out.println(response);
System.out.println(plainAnswer);
System.out.println(xmlAnswer);
System.out.println(htmlAnswer);
}
private static URI getBaseURI() {
return UriBuilder.fromUri("http://localhost:8080/com.vogella.jersey.first").build();
}
}

Operating System lab

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Operating System lab

Semelhante a Operating System lab (20)

Último

Último (20)

Operating System lab