The Problem with Threads

Transcription

1 The Problem with Threads Author Edward A Lee Presented by - Varun Notibala Dept of Computer & Information Sciences University of Delaware

2 Threads Thread : single sequential flow of control Model for concurrent programming Sequential computation Understandable, predictable, deterministic Threads result in loss of these features Methods to limit / eliminate these losses available But, not effective

3 Background End of Moore s law Performance gain achieved by parallelism Architecture design to exploit parallelism Dynamic dispatch, automatic parallelization Have we hit the limits in architecture design Alternatives available?? Programs should become parallel or

4 Problem w/ threads WHY? Concurrent abstractions chosen for threads Don t represent concurrency in real world Concurrent programming using threads hard MAIN IDEA Replace sequence of steps with community of interacting entities

5 Some terminology Determinacy Predictability Reliability Pruning

6 Analogy Pruning Mutexes, semaphores Internal combustion engine with iron, hydrocarbon and oxygen. Move these randomly and prune to get the combustion engine..??

7 Example - Observer Pattern public class ValueHolder { private List listeners = new LinkedList(); private int value; public interface Listener { public void valuechanged(int newvalue); } public void addlistener(listener listener) { listeners.add(listener); }

8 Example - Observer Pattern public class ValueHolder { private List listeners = new LinkedList(); private int value; public interface Listener { public void valuechanged(int newvalue); } public void addlistener(listener listener) { listeners.add(listener); } public void setvalue(int newvalue) { value = newvalue; Iterator i = listeners.iterator(); while(i.hasnext()) { ((Listener)i.next()).value Changed(newValue); }

9 Example - Observer Pattern public class ValueHolder { private List listeners = new LinkedList(); private int value; public interface Listener { public void valuechanged(int newvalue); } public synchronized void addlistener(listener listener) { listeners.add(listener); }

10 Example - Observer Pattern public class ValueHolder { private List listeners = new LinkedList(); private int value; public interface Listener { public void valuechanged(int newvalue); } public synchronized void addlistener(listener listener) { listeners.add(listener); } public void setvalue(int newvalue) { List copyoflisteners; synchronized(this) { value = newvalue; copyoflisteners = new LinkedList(listeners); } Iterator i = copyoflisteners.iterator() ; while(i.hasnext()) { ((Listener)i.next()).value Changed(newValue); }

11 Observer pattern - Inference Prone to deadlocks Concurrent modification clash Most multithreaded programs have concurrency issues Multi-core architectures Will concurrency bugs might show up more often??

12 Aggressive pruning Better software engineering practice Daily builds, code review, regression tests Large projects still see concurrency bugs As late as 3-4 years of successful Language support for mutually exclusive locks and deadlock avoidance is not good Later versions of Java provide better mutual exclusion but are sophisticated

13 Aggressive pruning Design patterns transactional design Work on a data copy followed by commit or abort Transactions suited for intrinsic nondeterministic interactions But not to build determinate concurrent interactions Patterns encapsulated into libraries concurrent data structures in Java 5.0

14 Aggressive pruning Extension of languages with keywords - Split-C, Cilk Gauva language constrains java to prohibit access of unsynchronised objects from multiple threads Explicit separation of read and write locks Promises Formal program analysis like Blast and Intel thread checker to identify potential concurrency bugs

15 Aggressive pruning - Limits Discussed methods prune non-determinism Still result in highly non-deterministic code Good for intrinsically non-deterministic applications But not for achieving deterministic aims

16 Alternatives to threads Each component is a process Merge block specifies a conditional rendezvous Two possible three way rendezvous interactions Observer pattern implemented using rendezvous based coordination language

17 Alternatives to threads The merge block represents the co-ordination language This handles the synchronization It can be implemented using other design models PN Director Kahn process network for concurrency SR Director Synchronous reactive director

18 Alternatives to threads The diagram clearly expresses the observer pattern The program expression is totally deterministic Except - merge block, which encompasses all the non determinism Value consumer and observer see values in same order Leads to a community of interacting entities Replacing sequence of steps

19 Overcoming nondeterminism Deterministic interleaving using rendezvous

20 Alternatives to threads - Inference Split design into deterministic stand alone blocks Introduce non-determinism judiciously This style of concurrency is AKA actor oriented design Supplement of control flow oriented design Some examples of actor oriented design OpenMP MPI

21 Alternatives to threads - Inference Languages Erlang support message passing concurrency Ada Rendezvous Functional languages Emphasize on determinism Less explicitly concurrent So there is no single alternative solution available

22 Challenges and Opportunities Obstacles Notion of programming is deep rooted in sequential paradigm Alternatives like MPI, OpenMP and thread libraries Nil / very less syntactic changes to existing languages Semantically these make programming non deterministic

23 Coordination Languages Build on existing languages Answer Coordination languages CL Specify syntax only for coordination Leave the other syntax to already popular general purpose languages

24 Obstacles for CL Inertia and acceptance UML as ice breaker Design and use of complimentary features of two languages Pitfalls in design of good CL Scalability Modularity Adapt theory of computation to enhance concurrent computing

25 Conclusion Even non trivial multithreaded programs are incomprehensible Reason: Abstraction chosen for concurrency is threads Better design patterns, improved languages, formal methods Only help chip away the unnecessary enormous non determinism of threading model

26 Conclusion Deterministic ends should be achieved using deterministic means Non-determinism should be judiciously introduced Only where necessary Should be made explicit Threads must be relegated to the engine room of computing, to be suffered by expert technology providers

27 QUESTIONS