SPL/2010SPL/2010

Synchronization

1

SPL/2010SPL/2010

Overview

● synchronization mechanisms in modern RTEs

● concurrency issues● places where synchronization is needed

● structural ways (design patterns) for exclusive access

2

SPL/2010SPL/2010

Overview

● synchronization mechanism in Java RTE● Visibility and re-ordering● Design patterns to avoid safety issues:

● monitor pattern.● client side locking.● class composition.● version iterattor.

3

SPL/2010SPL/2010

Java Synchronization - concurrent objects safety

● threads which access the same object concurrently.

● safety - synchronize access to internal state of the object

4

SPL/2010SPL/2010

class Even

5

SPL/2010SPL/2010

● if threads can access internal state of object concurrently - not safe● @invariant is not guaranteed● code perfectly safe in sequential environment

6

SPL/2010SPL/2010

Visibility and Reordering – unsafe constructs in concurrent execution

● Visibility - when threads see values written to memory by other threads

● Reordering - compiler / RTE change code to optimize it

7

SPL/2010SPL/2010 8

SPL/2010SPL/2010

anonymous class - class that has no name

● combines class declaration and instance creation in one step in-line

● allows "on the fly" creation of object● reduce the number of .java files necessary● class used in specific situation: Comparator● compiler will create separate class files:

ClassName$SomeNumber.class

9

SPL/2010SPL/2010

Inlining

11

SPL/2010SPL/2010

Inlining

● Inline expansion - compiler optimization that replaces a function call site with the body of the callee.● improve time and space usage at runtime, at

cost of binary file size

12

SPL/2010SPL/2010 13

SPL/2010SPL/2010

output = 0

● thread t does not "see" the change to the state of d performed in main thread● thread main - implicitly created by JVM● executes main() method● main calls d.set(10): 10 is written to

memory: i_ member of: VisibilityDemo object ● t reads from i_ (d.get() )

– Java does not guarantee t sees most recent value written to this memory location

14

SPL/2010SPL/2010

Re-ordering

● compiler must be able to re-order simple instructions to optimize our code

15

SPL/2010SPL/2010

Re-ordering

● compiler guarantees safe reordering in non-concurrent execution environments.

● order of operations is that the sequence will end with operation 4

16

SPL/2010SPL/2010

Re-ordering

● in concurrent environments, reordering may harm

17

SPL/2010SPL/2010

“must-happen-before”

● compiler would not reorder if "must-happen-before" constraint

18

SPL/2010SPL/2010

“must-happen-before”

● "must-happen-before“ - call to any (non-inline) function ● compiler would not go recursively into that

function

19

SPL/2010SPL/2010

"synchronized" construct in Java

● allow only one thread at a time to enter a specific method of an object

● synchronized keyword to method's declaration

20

SPL/2010SPL/2010

synchronized

● Java coordinates actions of threads on object: ● keyword  before method name in class

definition:– public synchronized int add() - only one thread

is allowed to enter– constructors cannot be synchronized - syntax

error (only thread that creates an object access its constructor)

21

SPL/2010SPL/2010

synchronized

● Java RTE ensures that only one thread access this method.

● solves visibility and reordering problems; ● "write" to memory during synchronized code

section is guaranteed to be returned to all "read" operations following it

22

SPL/2010SPL/2010

How "synchronized" is implemented?

● Java mechanism - use it better / avoid common pitfalls● each object inside JVM (at runtime) has

a lock ("monitor") ● JVM maintain/initialize locks. ● cannot access locks explicitly● access implicitly using synchronized 

23

SPL/2010SPL/2010

locks

● locks are in one of two states;

1. in possession of thread

2. available● thread T tries to acquire the lock of any

object. ● if available – lock transferred to T possession ● otherwise, T sleeps (queue) until lock

available ● T wakes up and tries to acquire lock

24

SPL/2010SPL/2010

synchronized

● each thread, calling the method, must first acquire lock.

● when thread exits – thread releases lock

25

SPL/2010SPL/2010

The cost of locks – time, concurrency

● memory sync.: after thread exits – memory of all threads synchronize with main memory ● thread may cache copies of memory in its

own memory (e.g., CPU registers / CPU cache)

● blocking: threads must wait for each other

26

SPL/2010SPL/2010

When to Use Synchronization

● mutable variable accessible from different threads must be protected with lock ● else, you may be hit by re-ordering problems

● monitor pattern - internal state of object is encapsulated. ● objects are responsible to synchronize access

to state: synchronized get() /set() 

27

SPL/2010SPL/2010

When to Use Synchronization

● invariant involving several members - synchronized with same lock.

● never lock large parts of code. ● minimize code sections which use locking

28

SPL/2010SPL/2010

Synchronized Properties

● synchronized keyword is not part of the method signature.

● synchronized keyword cannot be specified in an interface.

● constructors cannot be  synchronized● no point - as long as constructor is not complete, object

instance is not accessible to other threads, unless…● static method as synchronized - lock associated with

the class to be used● (each class in Java is also an object on its own)

● Java locks are Reentrant: same thread holding the lock can get it again and again.

29

SPL/2010SPL/2010

Statics

● Access to static fields protected via synchronized static methods and blocks. Static synchronization employs the lock possessed by the Class object

● static lock for class C can also be accessed inside instance methods via:

synchronized(C.class) { /* body */ }

30

SPL/2010SPL/2010

Locks are Reentrant

31

SPL/2010SPL/2010

Locks are Reentrant/Recursive

● thread, T, acquired the lock of Even object ● in add() , T will be able to enter

doSomething()  - T already possesses lock of same object.

32

SPL/2010SPL/2010

● synchronized instance methods in subclasses employ the same lock as in their superclasses

● synchronization in an inner class method is independent of its outer class

33

SPL/2010SPL/2010

Locks are Reentrant/Recursive

● Reentrant locks are implemented using counter

● same thread may acquire lock multiple time, consecutively, without releasing

● each time the lock is acquired, an internal counter is incremented.

● lock is unavailable whenever counter > 1. ● when thread releases the lock, the counter value

is decremented by 1. ● when counter reaches 0, the lock is then

available34

SPL/2010SPL/2010

Locking a Specific Object

●  synchronized keyword to method declaration ● implicitly uses the lock of current object

● explicitly request to lock a specific object we wish to acquire● not advised to use synchronized blocks. It is

usually better to define synchronized methods

35

SPL/2010SPL/2010 36

SPL/2010SPL/2010

Vector: addIfAbsent()

● addIfAbsent()● new class – Vector hold some information● javadoc - Vector class is thread-safe● add an element only if missing

● Is it thread safe?

37

SPL/2010SPL/2010

Not thread safe

38

SPL/2010SPL/2010

Another solution?

39

SPL/2010SPL/2010

incorrect solution

● lock protecting addIfAbsent() may be different from lock protecting add()

● not sure that add() is synchronized ● implementation of Vector may change -

Vector can become not thread safe

40

SPL/2010SPL/2010

Design Patterns to Enforce Safety

● Composition / Client Side Locking

41

SPL/2010SPL/2010

Composition / Containment

● "almost" reimplementing the functionality of Vector. Why not extend Vector class and add the function we want? ● do not know how the class Vector protects

itself from concurrent access. ● do not know/not have access to, which

objects are used for synchronized access● good design strategy to have a basic (non

thread safe) object and a thread safe version of it.

42

SPL/2010SPL/2010

Composition / Containment

● wrapper around Vector class:● Enforces right synchronization policy● Delegates all calls (after synchronization is

verified) to underlying implementation class.

43

SPL/2010SPL/2010 44

SPL/2010SPL/2010

Composition / Containment

● we know exactly which lock is used to synchronize access to our vector.

● best applied in situations where: ● we are not sure/ do not know the internal

implementation of an object● implementation of object may change

without our knowledge

45

SPL/2010SPL/2010

● all methods are synchronized.● no public fields or encapsulation

violations.● methods are finite (no infinite loops or

unbounded recursion)● all fields are initialized to a consistent

state in constructors.● state of object is consistent

46

SPL/2010SPL/2010

Client Side Locking

● we may know the identity of the object which is used for synchronization● Vector class uses its own monitor (lock) to

achieve synchronization

47

SPL/2010SPL/2010

Client side locking

● only when we know internal implementation ● Vector uses monitor

● not when unknown internal implementation

● not when implementation may change

48

SPL/2010SPL/2010

Client side locking

● not OO: ● responsibility of synchronization to clients

instead of centralizing it in object● cannot ensure consistency among ALL clients

: – If client does not synchronize correctly, then ALL

the code will behave incorrectly.

● better to enforce safety on provider side

49

SPL/2010SPL/2010

Version Iterators

● Iterators and Generics

● casting is bad - introduces clutter ● programmer knows what kind of data ● run time error – if wrong cast

50

SPL/2010SPL/2010

Generics

● programmers express intent ● restrict a list to contain a particular data type

51

SPL/2010SPL/2010

List, Iterator interfaces (java.util)

52

SPL/2010SPL/2010

Type parameters <T>

● <> - declarations of type parameters for List and Iterator interfaces

● used in declaration, instead ordinary types

● when used with actual type <Integer> all occurrences of formal type parameter <E> are replaced by Integer

53

SPL/2010SPL/2010

Version iterators

● process Vector of Integers one at a time

54

SPL/2010SPL/2010

Concurrency problem

● consider  vec_ is shared by several threads, adding/removing elements concurrently. ● element pointed by iterator is deleted?● new element is added at the beginning ?

55

SPL/2010SPL/2010

Solution – synchronize loop

● synchronize iteration on vector● body of loop may be arbitrarily long - locking

the entire vector for the entire loop ● no access to object used to synchronize

56

SPL/2010SPL/2010

Solution - immutable

● create a temporary copy of vector● local to current thread● iterate over copy● inappropriate to copy the entire data

structure● need to lock the vector during copy

operation, – if vector class does not offer a thread-safe cloning

57

SPL/2010SPL/2010

Solution - fail-fast

● Vector iterators are fail-fast:● if element is added/removed after iterator

was created except through Iterator's remove or add ConcurrentModificationException is thrown.

58

SPL/2010SPL/2010

Solution - fail-fast

● useful for many readers few writers model

● fail-fast in java is on best-effort basis. ● fail-fast behavior of iterators in Java should

be used only to detect bugs.

59

SPL/2010SPL/2010

Version iterators

● Idea:● maintain version number that is incremented

upon each update to collection. ● iterator check value whenever asked for next

element and throw exception if changed● implementation of fail-fast iterators

60

SPL/2010SPL/2010 61

SPL/2010SPL/2010 62

Code-block synchronized version

SPL/2010SPL/2010

Synchronized methods and blocks

synchronized void f() { /* body */ }

is equivalent to:

void f() { synchronized(this) { /* body */ } }

63

SPL/2010SPL/2010

More Synchronization Primitives

● Lock interface ● test that a lock can be acquired without

blocking● tryLock() - returns if lock is not available ● Lock objects work like the implicit locks used

when accessing a synchronized code segment.

● Only one thread can own a Lock object at a time.

● Semaphore Exchanger Latch 64