The Problem with Threads - Organization Programming Language | CSE 452, Papers of Programming Languages

Material Type: Paper; Professor: Dillon; Class: Organization Programming Lang; Subject: Computer Science & Engineering; University: Michigan State University; Term: Fall 2006;

Typology: Papers

Pre 2010

Uploaded on 07/29/2009

koofers-user-1z5
koofers-user-1z5 🇺🇸

10 documents

1 / 15

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
L. Dillon, CSE 452, Fall 2008 1
The Problem with Threads
Edward A. Lee
EECS Department
University of California at Berkeley
January 2006
They [threads] discard the most essential and appealing
properties of sequential computation: understandability, pre-
dictability, and determinism. Threads . . . are wildly nonde-
terministic, and the job of the programmer becomes one of
pruning that nondeterminism.
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download The Problem with Threads - Organization Programming Language | CSE 452 and more Papers Programming Languages in PDF only on Docsity!

The Problem with Threads

Edward A. Lee EECS Department University of California at Berkeley January 2006 “ They [threads] discard the most essential and appealing properties of sequential computation: understandability, pre- dictability, and determinism. Threads... are wildly nonde- terministic, and the job of the programmer becomes one of pruning that nondeterminism.

  • Very brief introduction to concurrent programming
  • Shows the “essence” of the problem w/ threads from a computa- tional viewpoint
  • Illustrates the practical implications of the problem via − A simple, but useful example (observer pattern) − An anecdote from a real project using threads (see paper)
  • Lightly surveys aggressive pruning techniques
  • Illustrates and argues for an alternative to threads & pruning: concurrent coordination languages

Outline of the paper

Computational model of threads

Notation: B = {0, 1} (^) binary digits N = {0, 1, 2, ...} (^) natural numbers B ** = B

, B ~ sequences of 0’s and 1’s B ** < B ** partial functions over B ** Defn1. An imperative machine is a pair ( A, c ) where

  • A ⊂ ( B ** < B ** ) is a finite set of actions ( instructions )
  • c : B ** <N is a control function

Defn2. The halt instruction halt ∈ A is the identity function on B

** .

That is, halt ( b ) = b, for all b ∈ B

** .

Defn3. A sequential program p of length m is a sequence of in- structions p : N" A where p ( n ) = halt , for all n $ m. Defn4. A thread is an execution of a sequential program p on a machine ( A,c ) which is defined by a sequence on B ** , b 0 , b 1 , b 2 , ..., where b n+ = p ( c ( b n ) ) ( b n ) for n $ 0.

Model of computation

state/I/O after n th instruction the ( n+1 ) st instruction state/I/O after ( n+1 ) st instruction Defn5. An of ( p 1 ; p 2 ), for sequential programs p 1 and p 2 , is a sequence on B ** , b 0 , b 1 , b 2 , ..., where b n+ = choose { p 1 ( c ( b n ))( b n ), p 2 ( c ( b n ))( b n ) } for n $ 0.

• Threads are wildly nondeterministic and job of the pro-

grammer is to prune away undesired nondeterminism.

• Argues that a better approach:

− Nondeterminism should be explicitly added to pro-

grams only where needed

Essential problem

Not thread safe:

Example: observer pattern

Listener valueChanged(...) ValueHolder Value value addListener( ... ) setValue( ... ) listeners

public void setValue(int nv) { value = nv; Iterator i = listeners.iterator(); while (i.hasNext()) { ((Listener)i.next()).valueChanged(nv); } } public void addListener(Listener nlis) { listeners.add(nlis); } T1: Thread : ValueHolder T1: Thread addListener(...) setValue(...) Data Race!

T1: Thread T1: Thread a: ValueHolder setValue(...) High-level race! b: Listener valueChanged(...) setValue(...) valueChanged(...) synchronized void setValue(int nv) { List copy; synchronized(this) { value = nv; copy = new LinkedList(listeners); } Iterator i = copy.iterator(); while (i.hasNext()) { ((Listener)i.next()).valueChanged(nv); } } Listener valueChanged(...) ValueHolder Value value addListener( ... ) setValue( ... ) listeners

• Rigorous software engineering (testing,inspections-see anecdote)

• Impose total order on locks and acquire them in order

− inflexible and brittle − non compositional ◊ locks needed are not specified in interface − symmetric access becomes very difficult

• Design patterns for concurrent programming

− implementing a CP pattern is subtle and tricky − properties of different design patterns do not compose

• Some notable high level CP design patterns

− Transactions—work on a copy of the data, then commit or abort ◊ Good for intrinsically nondeterminate situations (multiple competing actors) − MapReduce—large scale distributed processing of huge data sets ◊ Encapsulate in libraries for non-experts to use

Aggressive pruning

• Start with deterministic, composable mechanisms

• Introduce nondeterminism only where needed

Coordination approach (Ptolemy II)

Rendezvous director Value producer 2 Value producer 1 Value consumer Observer Merge Each icon is a Java program. Rendezvous Director indicates CSP-like composition of components. Merge indicates conditional rendezvous ( possible 3-way rendezvous)

Coordination approach (Ptolemy II)

PN director Value producer 2 Value producer 1 Value consumer Observer Merge PN Director indicates components communicate via message passing with unbounded FIFO channels and blocking reads. Annotation on Merge combinator indicates nondeterministic merge.