Transcript Slides

Lecture 13:
Concurring
Concurrently
CS201j: Engineering Software
University of Virginia
Computer Science
David Evans
http://www.cs.virginia.edu/~evans
Menu
• Subtyping Rules Review
– Overriding and Overloading
• Concurrency
17 October 2002
CS 201J Fall 2002
2
Substitution Principle
…
(in client code)
MysteryType1 mt1;
MysteryType2 mt2;
MysteryType3 mt3;
…
(anything could be here)
mt1 = mt2.m (mt3);
If the Java compiler is happy with this code, which of these are guaranteed
to be true:
a. The apparent type of mt2 is MysteryType2
b. At the last statement, the actual type of mt2 is MysteryType2
c. MysteryType2 has a method named m
d. The MysteryType2.m method takes a parameter of type MysteryType3
e. The MysteryType2.m method returns a subtype of MysteryType1
f. After the last statement, the actual type of mt1 is MysteryType1
17 October 2002
CS 201J Fall 2002
3
…
(in client code)
MysteryType1 mt1;
MysteryType2 mt2;
MysteryType3 mt3;
…
(anything could be here)
mt1 = mt2.m (mt3);
If the Java compiler is happy with this code, which of these are guaranteed
to be true:
a. The apparent type of mt2 is MysteryType2
TRUE: the apparent type is obvious from the declaration.
b. At the last statement, the actual type of mt2 is MysteryType2
FALSE: we only know the actual type <= MysteryType2
c. MysteryType2 has a method named m
TRUE
d. The MysteryType2.m method takes a parameter of type MysteryType3
FALSE: we only know it takes a parameter >= MysteryType3
e. The MysteryType2.m method returns a subtype of MysteryType1
TRUE: the assignment type checking depends on this
f. After the last statement, the actual type of mt1 is MysteryType1
FALSE: we only know that the actual type <= MysteryType1
17 October 2002
CS 201J Fall 2002
4
Subtyping Rules
class A {
public RA m (PA p) ;
}
…
(in client code)
MysteryType1 mt1;
MysteryType2 mt2;
MysteryType3 mt3;
…
mt1 = mt2.m (mt3);
If A is MysteryType2, what do we know about
RA and PA?
RA must be a subtype of MysteryType1:
RA <= MysteryType1
MysteryType3 must be a subtype of PA:
PA >= MysteryType3
17 October 2002
CS 201J Fall 2002
5
Subtyping Rules
…
(in client code)
class A {
MysteryType1 mt1;
public RA m (PA p) ;
MysteryType2 mt2;
}
MysteryType3 mt3;
class B extends A {
…
public RB m (PB a);
mt1 = mt2.m (mt3);
}
If B <= A, what do we know about RB and PB?
RB must be a subtype of RA: RB <= RA
PA must be a subtype of PB: PB >= PA
17 October 2002
CS 201J Fall 2002
6
Substitution Principle
…
(in client code)
class A {
MysteryType1 mt1;
public RA m (PA p) ;
MysteryType2 mt2;
}
MysteryType3 mt3;
class B extends A {
…
public RB m (PB a);
mt1 = mt2.m (mt3);
}
Substitution Principle:
Parameters
PB >= PA
Preconditions
pre_A  pre_B
Result
Postconditions
17 October 2002
RB <= RA
post_B  post_A
CS 201J Fall 2002
7
Substitution Principle / Eiffel
…
(in client code)
class A {
MysteryType1 mt1;
public RA m (PA p) ;
MysteryType2 mt2;
}
MysteryType3 mt3;
class B extends A {
…
public RB m (PB a);
mt1 = mt2.m (mt3);
}
Substitution Principle
Eiffel
Parameters PB >= PA
PB <= PA
Preconditions pre_A  pre_B
pre_B  pre_A
Result
RB <= RA
RB <= RA
Postconditions post_B  post_A post_B  post_A
17 October 2002
CS 201J Fall 2002
8
Overloading and Overriding
• Overriding: replacing a supertype’s
method in a subtype
– Dynamic dispatch finds method of actual type
• Overloading: providing two methods with
the same name but different parameter
types
– Statically select most specific matching
method of apparent type
17 October 2002
CS 201J Fall 2002
9
Overloading Example
public class Overloaded extends Object {
public int tryMe (Object o) {
return 17;
}
public int tryMe (String s) {
return 23;
}
}
public boolean equals (String s) {
return true;
public boolean equals (Object)
}
is inherited from Object
17 October 2002
CS 201J Fall 2002
10
public class Overloaded {
public int tryMe (Object o) {
return 17;
}
public int tryMe (String s) {
return 23;
static public void main (String args[]) {
}
Overloaded over = new Overloaded ();
public boolean equals (String s) {
System.err.println (over.tryMe (over));
return true;
System.err.println (over.tryMe (new String ("test"))); }
}
Overloading
Object obj = new String ("test");
System.err.println (over.tryMe (obj));
System.err.println (over.equals (new String ("test")));
System.err.println (over.equals (obj));
Object obj2 = over;
System.err.println (obj2.equals (new String ("test")));
}
17 October 2002
CS 201J Fall 2002
17
23
17
true
false
false
11
Overkill
• Overloading and overriding together can
be overwhelming!
• Avoid overloading whenever possible:
names are cheap and plentiful
• One place you can’t easily avoid it:
constructors (they all have to have the
same name)
17 October 2002
CS 201J Fall 2002
12
My Favorite C++ Program
#include<stdio.h>
(On notes, for experts only)
class A {
public: void other () { printf("is an empty func in A\n"); };
virtual void other (class A *a) { printf("In A\n"); }
};
class B: public A {
public: void other (class B *b) { printf("In B\n"); }
};
class C: public A {
public: void other (class C *c) { printf("In C\n"); }
};
void main(void) {
A a; B b; C c;
A *aPtr = &a; B *bPtr = &b; C *cPtr = &c;
aPtr = bPtr;
aPtr->other(bPtr);
bPtr->other();
}
17 October 2002
CS 201J Fall 2002
13
Concurrency
17 October 2002
CS 201J Fall 2002
14
Our computer can only do one
instruction at a time, why would
we want to program pretending
it can do many things at once?
17 October 2002
CS 201J Fall 2002
15
Concurrent Programming
• Some problems are clearer to program
concurrently:
– Modularity
• Don’t have to explicitly interleave code for different
abstractions (especially: user interfaces)
• High-level interactions – synchronization,
communication
– Modeling
• Closer map to real world problems: things in the
real world aren’t sequential
17 October 2002
CS 201J Fall 2002
16
Concurrency in Java
public class Thread implements Runnable {
// OVERVIEW: A thread is a thread of execution in a program.
// The Java Virtual Machine allows an application to have
// multiple threads of execution running concurrently.
public Thread (Runnable target)
// Creates a new Thread object that will run the target.
public void start ()
// Starts a new thread of execution.
… many other methods
}
17 October 2002
CS 201J Fall 2002
17
Making a
Thread
public class Thread implements Runnable {
public Thread (Runnable target)
public void start ()
… many other methods
}
// from PS5 Grid class:
public void startObjects()
// EFFECTS: Start all object threads.
{
Enumeration els = simobjects.elements ();
while (els.hasMoreElements ()) {
SimObject current = (SimObject) els.nextElement ();
Thread simObjectThread = new Thread (current);
simObjectThread.start ();
}
What do you know about SimObject type?
}
17 October 2002
CS 201J Fall 2002
18
Runnable
public interface Runnable {
public void run()
When an object implementing interface Runnable is
used to create a thread, starting the thread causes the
object's run method to be called in that separately
executing thread. The general contract of the
method run is that it may take any action
whatsoever.
}
So, to be a subtype of Runnable, SimObject must have a method
void run () with no preconditions and any postconditions it wants.
17 October 2002
CS 201J Fall 2002
19
Making a Runnable
abstract public class SimObject implements Runnable {
…
public void run ()
// EFFECTS: Executes one turn by calling the
// executeTurn method, and sleeps for a time
// and repeats.
{
while (true) {
executeTurn ();
delay (TURN_DELAY + random.nextInt(TURN_RANDOM));
}
}
17 October 2002
CS 201J Fall 2002
20
Actually…
abstract public class SimObject implements Runnable {
…
public void run ()
// REQUIRES: this has been initialized
//@also_requires isInitialized
// EFFECTS: Executes one turn by calling the
// executeTurn method, and sleeps for a time
// and repeats.
{
We are violating the substitution principle!
…
SimObject.run() has a stronger precondition
}
than Runnable.run().
17 October 2002
CS 201J Fall 2002
21
Concurrency
• Making a concurrent Java program is
easy:
Make a subtype R of Runnable
new Thread (new R ()).start ()
• Making a concurrent Java program that
behaves correctly is really, really hard!
17 October 2002
CS 201J Fall 2002
22
Scheduling Meetings
• Alice wants to schedule a meeting with
Bob and Colleen
Bob
“When can
you meet
Friday?”
Alice
“When can
you meet
Friday?”
Colleen
“11am or 3pm”
“9am or 11am”
Picks meeting
time
Reserves 11am
for meeting
17 October 2002
“Let’s meet
at 11am”
“Let’s meet
at 11am”
CS 201J Fall 2002
Reserves 11am
for meeting
23
Partial Ordering of Events
• Sequential programs give use a total
ordering of events: everything happens in
a determined order
• Concurrency gives us a partial ordering of
events: we know some things happen
before other things, but not total order
Alice asks to schedule meeting before Bob replies
Alice asks to schedule meeting before Colleen replies
Bob and Colleen both reply before Alice picks meeting time
Alice picks meeting time before Bob reserves time on calendar
17 October 2002
CS 201J Fall 2002
24
Race Condition
Bob
Doug
“When can
you meet
Friday?”
“When can
you meet
Friday?”
Alice
“When can
you meet
Friday?”
Colleen
“9, 11am or 3pm”
“9am or 11am”
“9, 11am or 3pm”
“Let’s meet
at 11am”
Reserves 11am
for Doug
“Let’s meet
at 11am”
Picks meeting
time
“Let’s meet
at 11am”
“I’m busy
then…”
17 October 2002
CS 201J Fall 2002
25
Preventing Race Conditions
• Use locks to impose ordering constraints
• After responding to Alice, Bob reserves all
the times in his response until he hears
back (and then frees the other times)
17 October 2002
CS 201J Fall 2002
26
Locking
Doug
“When can
you meet
Friday?”
Bob
“When can
you meet
Friday?”
Alice
“When can
you meet
Friday?”
Colleen
“9, 11am or 3pm”
“9am or 11am”
Locks calendar
“3pm”
“Let’s meet
at 11am”
Picks meeting
time
“Let’s meet
at 11am”
“Let’s meet
at 3”
17 October 2002
CS 201J Fall 2002
27
Doug
“When can
Bob
you meet
Friday?”
“When can
you meet
Friday?”
Can’t schedule
meeting, no
response from
Bob
17 October 2002
Deadlocks
Alice
“When can
you meet
Friday?”
Colleen
“When can
you meet
Friday?”
Locks
calendar
for Doug,
can’t
respond to
Alice
“9, 11am or 3pm”
Locks calendar
for Alice, can’t
respond to Doug
CS 201J Fall 2002
Can’t schedule
meeting, no
response from
Colleen
28
Why are threads hard?
• Too few ordering constraints: race conditions
• Too many ordering constraints: deadlocks
• Hard/impossible to reason modularly
– If an object is accessible to multiple threads, need to
think about what any of those threads could do at any
time!
• Testing is even more impossible than it is for
sequential code
– Even if you test all the inputs, don’t know it will work if
threads run in different order
17 October 2002
CS 201J Fall 2002
29
Charge
• Computers are single-threaded machines
that provide their owner the illusion of
multiple threads.
• Brains are multi-threaded machines that
provide their owner with the illusion of a
single thread.
• Practice with races/deadlocks on Tuesday,
no class on Thursday
• Return exams
17 October 2002
CS 201J Fall 2002
30