Outline 0024 Spring 2010 12 :: 2 Synchronization, revisited Two - PowerPoint PPT Presentation

Outline 0024 Spring 2010 – 12 :: 2 –

Synchronization, revisited Two aspects of synchronization Avoid that a thread sees an object in an inconsistent state  As defined by the programmer ’ s design Ensure that all threads see all updates  Threads must see updates in order Synchronized methods ensure that both aspects are dealt with  Provided synchronized methods are used for all accesses Volatile fields deal with the second aspect  Only basic types are available 0024 Spring 2010 – 12 :: 3 –

Purpose of synchronization: avoid race conditions that present an intermediate/inconsistent state  Java allows you to establish a critical section (“synchronized block” resp. “synchronized method”) but no control of the order in which threads enter the critical section  An event queue provides a mechanism to ensure that threads see the object in stable state  Still, no control on order of entry  All we know is that the condition is met Large critical sections not a good design: only races within thread-unsafe part of a program are dangerous  Two options: volatile variables or smaller synchronized methods 0024 Spring 2010 – 12 :: 4 –

Another problem 0024 Spring 2010 – 12 :: 5 –

More details 0024 Spring 2010 – 12 :: 6 –

Problems to avoid resp to address 0024 Spring 2010 – 12 :: 7 –

What is fairness? 0024 Spring 2010 – 12 :: 8 –

More (un)fairness 0024 Spring 2010 – 12 :: 9 –

Person 0024 Spring 2010 – 12 :: 10 –

Person details 0024 Spring 2010 – 12 :: 11 –

Person details, part 2 0024 Spring 2010 – 12 :: 12 –

Parameters 0024 Spring 2010 – 12 :: 13 –

Try different strategies … 0024 Spring 2010 – 12 :: 14 –

0024 Spring 2010 – 12 :: 15 –

Data transfers and synchronization Consider past parallel programs Standard situation: producer - consumer  Assume semaphore notEmpty, notFull  Init notFull to N (# of buffer elements), notEmpty to 0 Producer: loop { produce(data); // one item per buffer element notFull.p(); append (data, buffer); notEmpty.v(); } 0024 Spring 2010 – 12 :: 16 –

Consumer Consumer: loop { notEmpty.p(); retrieve (data, buffer); notFull.v(); consume(data); } 0024 Spring 2010 – 12 :: 17 –

Recall assignment #3 0024 Spring 2010 – 12 :: 18 –

Buffer.read 0024 Spring 2010 – 12 :: 19 –

Buffer.write 0024 Spring 2010 – 12 :: 20 –

Synchronized = exclusive use 0024 Spring 2010 – 12 :: 21 –

Another example 0024 Spring 2010 – 12 :: 22 –

Variation 0024 Spring 2010 – 12 :: 23 –

Message passing Idea: couple data transfer to synchronization Producer: “sends” data to consumer Consumer: “receives” data from producer 0024 Spring 2010 – 12 :: 24 –

More details Unit of transfer (“message”)  One item How does the consumer identify the producer?  And how does the producer ensure that data are directed towards the consumer What should the consumer do if there are no messages? Should messages be buffered? 0024 Spring 2010 – 12 :: 25 –

Synchronous vs asynchronous Synchronous: sender and receiver must “join” (rendez- vous) to exchange message  Close coupling of both threads Asynchronous: no coupling  Implies the use of buffers 0024 Spring 2010 – 12 :: 26 –

Naming Simple model: channels are known globally Send: put data into channel ch  ch ! data  ch <- data  put(ch, data) Receive: get data from channel  ch ? data  ch -> data  get(ch, data) 0024 Spring 2010 – 12 :: 27 –

More complicated models support channel variables  Naming or directory service 0024 Spring 2010 – 12 :: 28 –

CSP: communicating sequential processes Influential model proposed by C. A. R. Hoare Used in Ada, occam Synchronous communication with global channels 0024 Spring 2010 – 12 :: 29 –