Concurrent Programing

  • View
    215

  • Download
    0

Embed Size (px)

Text of Concurrent Programing

  • 8/4/2019 Concurrent Programing

    1/74

    Concurrent Programming

    Eitan Farchi

  • 8/4/2019 Concurrent Programing

    2/74

    IBM Labs in Haifa

    2 Contest

    Outline

    Background

    Development methodology

    Critical section, semaphores and monitors

    Development methodology (revisited)

    Threads and locks in Java

    Asynchronous message passing and logical time

  • 8/4/2019 Concurrent Programing

    3/74

    IBM Labs in Haifa

    3 Contest

    Background

    In the late 1960 operating systems were organized as concurrentprograms, with processes managing devices and executing user tasks

    a process is an abstraction of a processor

    process = (code, heap, registers, stack)

    thread is a light process, it belongs to a process and shares itsheap. thread = (program, registers, stack)

    Registers are scoped to the thread

    processes execute one at a time in an interleaved way

    Technology evolved to produce a variety of shared memory, messagepassing and communication network multiprocessors

    process communication abstracts the available hardwarecommunication

    Multiprocessors actually execute in parallel

  • 8/4/2019 Concurrent Programing

    4/74

  • 8/4/2019 Concurrent Programing

    5/74

    IBM Labs in Haifa

    5 Contest

    Background (Continued)

    Processes communicate using shared variables or messages

    Communication requires synchronization to ensure mutual exclusionor condition synchronization

    Mutual exclusion - critical section of statements that access shared

    objects are not executed at the same time Condition synchronization - a process delays if necessary until a given

    condition is true

  • 8/4/2019 Concurrent Programing

    6/74

    IBM Labs in Haifa

    6 Contest

    Example producer and consumer

    Communicate using a shared buffer

    The producer (sender) writes to the buffer and the consumer (reader)reads from the buffer

    Mutual exclusion is used to ensure that the sender and the receiver do

    not access the buffer at the same time Condition synchronization is used to ensure that

    a message is not received before it has been sent and

    a message is not overwritten before it has been received.

  • 8/4/2019 Concurrent Programing

    7/74

    IBM Labs in Haifa

    7 Contest

    Background (Continued)

    At run time

    The state of a process is the state of its heap (shared variables,shared objects), stack, registers, and hidden variables (e.g., theprogram counter)

    Processes create new child processes (fork() - Unix)A process is part of a concurrent program if it communicates with

    other processes

    The rate of execution of each process is unknown

    No assumption should be made on a process rate

    Also see bugPatternPreventionAndReview presentation

  • 8/4/2019 Concurrent Programing

    8/74

    IBM Labs in Haifa

    8 Contest

    Background (Continued)

    At run time A process transforms its state by executing statements

    Each statements consists of a sequence of atomic actions that makeindivisible transformationse.g., uninterruptible machine instructions that load and store registersif is executed, you can not observe a state in which Y is not

    equal to ZClear understanding of which source level operations are atomic is veryimportantStoring and loading of long and double in Java are not necessarily atomic

    (also see the concurrentBugPattern presentation)

    The trace/history/interleaving of a particular execution is a sequence ofatomic actions

    Even parallel execution can be modeled in this way The effect of executing a set of atomic actions in parallel is equivalent to

    executing them in some arbitrary order

    The state transformation caused by atomic actions is indivisible and can notbe effected by other actions

  • 8/4/2019 Concurrent Programing

    9/74

    IBM Labs in Haifa

    9 Contest

    Concurrent execution semantics is definable using a small setof rules

    (c1, s1) s2 => (c1 || c2, s1) -> (c2, s2)

    (c1, s1) s2 => (, s1) s2

    (b, s1) true and (c, s1) s2 => (, s1) s2

  • 8/4/2019 Concurrent Programing

    10/74

    IBM Labs in Haifa

    10 Contest

    Background scheduling policies

    A process is eligible to run when it is not waiting on event

    A process can wait for a page to be swapped from the disk

    The page can be part of the processes or part of a read file operation

    A process can wait in the socket accept() API waiting for a message

    to arrive on the socket We will be interested in safety and liveness properties.

    Safety nothing bad happen

    Mutual exclusion

    Absence of deadlock

    Livness something good eventually happens

    Request for service will eventually be honored

  • 8/4/2019 Concurrent Programing

    11/74

    IBM Labs in Haifa

    11 Contest

    Background scheduling policies

    When several processes are eligible to run

    The scheduler determines which one will execute next

    Fairness is concerned with guaranteeing that processes get a chance toproceed

    Most liveness properties depend on fairness

    Scheduling policies

    Unconditional fairness eligible processes eventually run

    Weak fairness unconditional fair and

    If is eligible and B becomes true and remains true thenit eventually executes

    Strong fairness unconditional fair and

    If is eligible infinitely often then it eventually executes

  • 8/4/2019 Concurrent Programing

    12/74

    IBM Labs in Haifa

    12 Contest

    Scheduling policies examples

    var continue = true

    loop:: do continueskip od

    stop:: continue = false

    Unconditional fairness will ensure progress

    giving every one a chance (round robin, time slicing, etc) on a

    single processor

    execution of both processes on a multiple processors

    The above example has no blocking operation, when there are blockingoperations

    Every process gets a chance is weakly fair as every delayed

    process will eventually see its delay condition is true and proceed

  • 8/4/2019 Concurrent Programing

    13/74

    IBM Labs in Haifa

    13 Contest

    Scheduling polices examples (continued)

    var continue = true, try = false

    loop:: do continue try = true; try = false; od

    stop::

    Strong fairness eventually terminate as try is infinitely often true

    Weak fairness not terminate as try is not eventually true

    Impossible to device both practical and strongly fair

    Alternating on a single processor will be strongly fair but not

    practical andGiving every one a chance will not work

    On a multiple processor stop might always examine try when it isfalse (in small probabilty)

  • 8/4/2019 Concurrent Programing

    14/74

    IBM Labs in Haifa

    14 Contest

    Scheduling polices

    Avoid ensuring progress by making some condition infinitely often true

    Another example if

    All processes execute s = s +1, and

    Two processes execute 0 s = s -1>,

    FCFS (first come first served) policy will ensure all will makeprogress

  • 8/4/2019 Concurrent Programing

    15/74

    IBM Labs in Haifa

    15 Contest

    Process life cycle

    Actually there are more details relating to swapping the process frommain memory

    On a single processor only one process is running.

    A context switch the single process that is running is put to sleep

    and another process is giving the cpu and starts running An interrupt causes a change of control to the interrupt handler,

    otherwise the process still runs in the same context

    The Unix signal mechanism is an abstraction of hardware interrupts

    A process can sleep on an event. It is wakened up by the kernel and

    made ready for run only when the event becomes true

  • 8/4/2019 Concurrent Programing

    16/74

    IBM Labs in Haifa

    16 Contest

    Outline

    Background

    Development methodology

    Critical section, semaphores and monitors

    Development methodology (revisited)

    Threads and locks in Java

    Asynchronous message passing and logical time

  • 8/4/2019 Concurrent Programing

    17/74

    IBM Labs in Haifa

    17 Contest

    The testing/validation problem

    The number of possible interleavings is enormous

    For (a;b;c;e;f;g)||(h;I;j;k;l;m) of none blocking atomic actions thenumber of possible traces is 12!/(6!*6!) = 924

    Testing/reviewing all of the interleaving is out of the question

  • 8/4/2019 Concurrent Programing

    18/74

    IBM Labs in Haifa

    18 Contest

    Objectives

    Demonstrate design through abstraction levels

    Abstraction levels are determined by the synchronization primitivesbeing used

    Higher abstraction level synchronization primitives ->

    lower number of possible interleavingsMistakes are less likely

    Validate the design

    By reviewing the important interleavings at every abstraction level

    Higher abstraction level synchronization primitives are correctlyimplemented by lower abstraction level synchronization primitives

    Test an implementation using ConTest

  • 8/4/2019 Concurrent Programing

    19/74

    IBM Labs in Haifa

    19 Contest

    Abstraction level example

    means that i++ is atomic

    At a lower level constructor you would specify synchronized(o){i++}

    you will have to identify each other location in the program thataccess i and

    protect the access using the loc