ICS 313: Programming Language Theory

1. ICS 313:Programming Language Theory Chapter 13: Concurrency

2. Why Study Concurrency • Make effective use of multiprocessor machines • SIMD: Single Instruction Multiple Data • e.g., vector processors • MIMD: Multiple Instruction Multiple Data • e.g., distributed systems • Useful way to conceptualize some programming problems • The world is inherently concurrent • Programs are more modular when inessential timing dependencies are avoided

3. Categories of Concurrency • Physical concurrency: • Actually running at the same time on different processors • Logical concurrency: • Treated as if concurrent, but may be interleaved on shared processor(s) • Quasi-concurrency: • A single thread of control, e.g., coroutines • At the level of language design the issues are the same

4. Concurrency Example • (define (withdraw amount) •   (if (>= balance amount) •       (begin (set! balance (- balance amount)) •              balance) •       "Insufficient funds"))

5. Why Help is Needed • Can we just list the possible orders of events and make sure the wrong ones don’t happen? • (set! balance (- balance amount)) • How many possible orders for • Peter: (a) retrieve balance (b) compute difference. (c) store balance • Paul: (x) retrieve balance. (y) compute difference. (z) store balance (a, b, c, x, y, z) (a, b, x, c, y, z) (a, b, x, y, c, z) (a, b, x, y, z, c) (a, x, b, c, y, z) (a, x, b, y, c, z) … There are 20

6. Tasks • May be started implicitly • Invoker need not wait for completion • Control may not return to invoker • Scheduler manages sharing of processors between tasks • Tasks can be • New • Runnable: on the task ready queue • Running • Blocked: waiting for some event to complete • Dead

7. Synchronization • Synchronization controls order of task execution • Cooperation synchronization • When one task needs the result of the concurrent task • Example: Producer and consumer using a shared buffer • Competition synchronization • When one task is waiting for another task’s unrelated computation due to resource constraints • Example: Two producers writing to the same event log

8. Deadlock • Classic concurrency problem • Task A takes control of resource X • Task B takes control of resource Y • Task A needs Y to continue, so waits for B • Task B needs X to continue, so waits for A • Need competition synchronization

9. Semaphores • Guards controlling access are placed around code accessing the resource • P(resource) - wait (passeren) • (put your code to access resource here) • V(resource) - release (vrygeren) • Guards are implemented using a Semaphore data structure • Integer counting some resource • Queue storing tasks waiting for that resource

10. Wait and Release • wait(semaphore, caller) • if semaphore.counter > 0 then • decrement semaphore.counter • else • semaphore.queue.enqueue(caller) • run semaphore.queue.dequeue() • release(semaphore, caller) • if semaphore.queue.isEmpty() then • increment semaphore.counter • else • semaphore.queue.enqueue(caller) • run semaphore.qeueue.dequeue()

11. Evaluation of Semaphores • Problem: Semaphore itself is a shared data object. How to prevent simultaneous access? • Solution: some machines provide uninterruptable instructions • Problem: Cannot statically check correctness of use • If programmer leaves out a P or V, deadlock or resource overflow may result • “An elegant synchronization mechanism for an ideal programmer”

12. Monitors • Shared data structures become abstract data types • Implementation of the ADT guarantees integrity (i.e. that shared data structures are not accessed simultaneously) • Implementation may actually use semaphores, but the use of semaphores is generated by the compiler not the programmer

13. Processes in Concurrent Pascal • Looks like procedure, but just a template type process_name = process(parameters) local declarations process body end • Execution begun with init var myProcess: process_name … init myProcess(argments) • Runs indefinitely except when blocked

14. Monitors in Concurrent Pascal type monitor_name = monitor(parameters) declarations of shared variables definitions of local procedures definitions of exported procedures initialization code end • Access to shared variables is controlled

15. Example • type databbuf = monitor • declarations of buffer variables • procedure entry deposit(item : integer); • body • procedure entry fetch(var item: integer); • body • initialization code • end • type producer = process(buffer: databuf); • body • type consumer = process(buffer : databuf); • body • var myProducer : producer; • myConsumer : consumer; • myBuffer : databaf; • begin • Init myBuffer, myProducer(myBuffer), myConsumer(myBuffer); • end

16. Queues • Programmer must still handle logic of resource limitations • This is done with queue data type • Delay: similar to wait except that always blocks caller • Continue: similar to release but does nothing if queue is empty • Programmer handles counting

17. Evaluation of Monitors Good for competition synchronization because they abstract issues of concurrent access Have same problems as semaphores for cooperation synchronization (due to delay/continue) Inappropriate model for distributed systems (no shared memory)

18. Message Passing • Motivated by distributed systems • Tasks make requests of other tasks • Tasks should not have to accept requests until ready • Multiple simultaneous requests should be handled nondeterministically • Rendezvous: when one task is ready to send and the other task ready to receive a message

19. Ada Message Passing • Tasks have specification and body task EXAMPLE is entryENTRY(ITEM : in INTEGER); end EXAMPLE task body EXAMPLE is begin loop acceptENTRY(ITEM : in INTEGER) do … end ETNRY; end loop end EXAMPLE; • Queue associated with each entry • Caller blocked on call to entry until task reaches accept • Task blocked on accept until call made to entry

20. Concurrency in Java • Methods of class Thread • run: a method that can run concurrently • start: a method that calls run and returns immediately • yield: surrender time slice • sleep: stop for at least specified number of seconds • Two approaches • Extend Thread (overriding run with concurrent code) • Implement Runnable and make a Thread that has this object as a component

21. Competition Synchronization • Synchronized modifier on a method locks the instance class SharedObject { … public synchronized int accessObject(…) { … } public synchronized void updateObject(…) { … } } • Only one thread will be able to run either accessObject or updateObject at a time • Can also synchronize a statement or compound statement synchronized(evaluates-to-object) statement

22. Cooperation Synchronization Cooperation requires that processes communicate about whether one has provided what the other needs • We can express this as an arbitrary boolean condition • wait() is used to test to see if that condition is true, and queue thread if not try { while (!condition-test) wait(); do what needs to be done } catch(InterruptedExcepton e) {…} • notify() is used to tell threads waiting on the queue that the condition should be checked again

23. Semaphores in Java We can implement semaphors and monitors using Java’s facilities public class Semaphore { private int value; public Semaphore (int initial) { value = initial; } synchronized public void up() { ++value; notify(); } synchronized public void down() throws InterruptedException { while (value==0) wait(); --value; } } (Thanks to Jeff Magee & Jeff Kramer http://www-dse.doc.ic.ac.uk/concurrency/book_applets/SemaDemo.html)

24. See examples http://www-dse.doc.ic.ac.uk/concurrency/book_applets/concurrency.html Semaphore Demonstration NestedMonitor FixedNestedMonitor Dining Philosphers

25. End