SLIDE 1
– 12 :: 2 – 0024 Spring 2010
Outline 0024 Spring 2010 12 :: 2 Synchronization, revisited Two - - PowerPoint PPT Presentation
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
SLIDE 2
SLIDE 3
– 12 :: 3 – 0024 Spring 2010
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
SLIDE 4
– 12 :: 4 – 0024 Spring 2010
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
SLIDE 5
– 12 :: 5 – 0024 Spring 2010
Another problem
SLIDE 6
– 12 :: 6 – 0024 Spring 2010
More details
SLIDE 7
– 12 :: 7 – 0024 Spring 2010
Problems to avoid resp to address
SLIDE 8
– 12 :: 8 – 0024 Spring 2010
What is fairness?
SLIDE 9
– 12 :: 9 – 0024 Spring 2010
More (un)fairness
SLIDE 10
– 12 :: 10 – 0024 Spring 2010
Person
SLIDE 11
– 12 :: 11 – 0024 Spring 2010
Person details
SLIDE 12
– 12 :: 12 – 0024 Spring 2010
Person details, part 2
SLIDE 13
– 12 :: 13 – 0024 Spring 2010
Parameters
SLIDE 14
– 12 :: 14 – 0024 Spring 2010
Try different strategies …
SLIDE 15
– 12 :: 15 – 0024 Spring 2010
SLIDE 16
– 12 :: 16 – 0024 Spring 2010
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(); }
SLIDE 17
– 12 :: 17 – 0024 Spring 2010
Consumer
Consumer:
loop { notEmpty.p(); retrieve (data, buffer); notFull.v(); consume(data); }
SLIDE 18
– 12 :: 18 – 0024 Spring 2010
Recall assignment #3
SLIDE 19
– 12 :: 19 – 0024 Spring 2010
Buffer.read
SLIDE 20
– 12 :: 20 – 0024 Spring 2010
Buffer.write
SLIDE 21
– 12 :: 21 – 0024 Spring 2010
Synchronized = exclusive use
SLIDE 22
– 12 :: 22 – 0024 Spring 2010
Another example
SLIDE 23
– 12 :: 23 – 0024 Spring 2010
Variation
SLIDE 24
– 12 :: 24 – 0024 Spring 2010
Message passing
Idea: couple data transfer to synchronization Producer: “sends” data to consumer Consumer: “receives” data from producer
SLIDE 25
– 12 :: 25 – 0024 Spring 2010
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?
SLIDE 26
– 12 :: 26 – 0024 Spring 2010
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
SLIDE 27
– 12 :: 27 – 0024 Spring 2010
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)
SLIDE 28
– 12 :: 28 – 0024 Spring 2010
More complicated models support channel variables
Naming or directory service
SLIDE 29
– 12 :: 29 – 0024 Spring 2010