Temporal Constraints for Concurrent Object Synchronisation (talk)

(1)

Temporal Constraints for

Concurrent Object Synchronisation

WOOD, Warsaw 12.04.03

Vladimiro Sassone

with Giuseppe Milicia

(2)

What does Inheritance do, after all?

class _Buffer {

void _put(Object v) { ...; } void _get() { ...; }

... }

class _Lock { ...

void _lock() { ...; } void _unlock() { ...; } }

Influence Buffer inheriting behaviour from Lock.

class _{LockableBuffer} extends _Buffer, _Lock{ }

(3)

What does Inheritance do, after all?

class _Buffer {

... }

class _Lock { ...

(4)

What does Inheritance do, after all?

class _Buffer {

... }

class _Lock { ...

(5)

Objects and Concurrency

Objects

: A fundamental, state-of-the-art concept for engineering complex software systems. (Design Patterns, Refactoring, . . .)

Concurrency

: A fundamental technology to meet today’s demands on software functionalities. (Internet, Mobile and Embedded Devices, Software Agents, . . .)

Alas, a difficult marriage

Synchronisation

of concurrent activities and

_inheritance

do not mix:

Inheritance Anomaly

(_{Yonezawa [1987]})

So bad to justify

_banning

inheritance from OO languages! (America [1991])

The plan

Explain the phenomenon via examples;

Illustrate the driving lines of the main existing approaches;

(6)

Objects and Concurrency

Objects

Concurrency

Alas, a difficult marriage

Synchronisation

_inheritance

do not mix:

Inheritance Anomaly

So bad to justify

_banning

The plan

(7)

Objects and Concurrency

Objects

Concurrency

Alas, a difficult marriage

Synchronisation

_inheritance

do not mix:

Inheritance Anomaly

So bad to justify

_banning

The plan

(8)

Objects and Concurrency

Objects

Concurrency

Alas, a difficult marriage

Synchronisation

_inheritance

do not mix:

Inheritance Anomaly

So bad to justify

_banning

(9)

Concurrency and Interference

The problem

: x := 0; ( x := x + 1kx := x + 2 ). Then, x ∈ {1,2,3}.

The solutions:

Operational Mechanisms:

Semaphores and Locks, . . .

Linguistic Constructs:

Critical Regions and Monitors, . . .

Alternative Models:

Message Passing, Resource-Based, . . .

(10)

Concurrency and Interference

The problem

: x := 0; ( x := x + 1kx := x + 2 ). Then, x ∈ {1,2,3}.

The solutions:

Operational Mechanisms:

Semaphores and Locks, . . .

Linguistic Constructs:

Critical Regions and Monitors, . . .

(11)

The Java Concurrency Model

public class _Buffer {

protected Object[] buf;

protected int MAX, current = 0;

Buffer(int max) { MAX = max;

buf = new Object[MAX]; }

public synchronized Object _get() throws Exception { while (current <= 0) wait();

Object ret = buf[--current];

notifyAll(); return ret; }

public synchronized void put(Object v) throws Exception { while (current >= MAX) wait();

(12)

Business and Synchronisation Code

/o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o client /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o object

In

_{sequential programming}

, clients can be asked to behave well. E.g., don’t _get unless you have _put. (_{Synchronisation code} and _{Business code}.)

/o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o client /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o object /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o /o client

In

_{sequential programming}

, clients can be asked to behave well. E.g., don’t _get unless you have _put.

In

_concurrency

, the resource

_must

contain

_{synchronisation code}

. This results essentially in methods

_{not being available}

at certain moments in time.

Concurrent object oriented programs in common programming languages consist of

(13)

Business and Synchronisation Code

In

_{sequential programming}

In

_concurrency

, the resource

_must

contain

_{synchronisation code}

_{not being available}

(14)

Business and Synchronisation Code

In

_{sequential programming}

In

_concurrency

, the resource

_must

contain

_{synchronisation code}

_{not being available}

(15)

The Inheritance Anomaly

Inheritance Anomaly

: Adding a new method

_morally

unrelated, forces the redefinition of all other methods of a class.

class _Buffer { ...

void _put(Object el) {

if ("buffer not full") ... }

Object _get() {

if ("buffer not empty") ... }

}

Add a method

_freeze

.

Chances are that the _{synchronisation code} in _Buffer must be totally rewritten for that. All approaches to the anomaly so far consist of

_{disentangling}

business and

(16)

The Inheritance Anomaly

Inheritance Anomaly

_morally

class _Buffer { ...

Object _get() {

} Add a method

_freeze

.

_{disentangling}

business and

(17)

The Inheritance Anomaly

Inheritance Anomaly

_morally

class _Buffer { ...

Object _get() {

}

Add a method

_freeze

.

_{disentangling}

business and

(18)

Partitioning of States

State Partition

: Introduce an explicit _partition of the object’s state, and explicit

enabling conditions for methods.

Example

. In the case of _Buffer, choose _empty, _partial, _full and the declarations:

put: requires not _full

get: requires not _empty Then

Object _get() { ...

if ("buffer is now empty ") become _empty; else become _partial;

(19)

Partitioning of States

State Partition

: Introduce an explicit _partition of the object’s state, and explicit

enabling conditions for methods.

Example

. In the case of _Buffer, choose _empty, _partial, _full and the declarations:

put: requires not _full

get: requires not _empty

Then

Object _get() { ...

if ("buffer is now empty ") become _empty;

else become _partial; return res;

(20)

Partition of States

This solves the problem only very

_partially

.

Consider adding _get2 which retrieves

_two

elements at once. Then, the partition _empty and _full is not enough anymore.

Need to distinguish those states where there is exactly one element: _single.

Correspondingly, refine it to be:

get2: requires not _empty or _single

Object _get() { ...

else if ("buffer is singleton") become _single; else become _partial;

(21)

Partition of States

_partially

.

_two

Need to distinguish those states where there is exactly one element: _single. Correspondingly, refine it to be:

Object _get() { ...

(22)

Partition of States

_partially

.

_two

Need to distinguish those states where there is exactly one element: _single.

Correspondingly, refine it to be:

Object _get() { ...

(23)

History-Sensitiveness of Acceptable States

When methods’ enabling depends on the

_history

of objects, we have a form of the anomaly so-called

_{history-sensitive}

.

For instance, a method _withdraw available only after a method _authenticate has been completed.

(24)

History-Sensitiveness of Acceptable States

When methods’ enabling depends on the

_history

of objects, we have a form of the anomaly so-called

_{history-sensitive}

.

For instance, a method _withdraw available only after a method _authenticate has been completed.

(25)

History Buffer

public class _{HistoryBuffer} extends _Buffer { boolean afterGet = false;

public HistoryBuffer(int max) super(max);

public synchronized Object _gget() throws Exception { while ( current <= 0 || afterGet ) wait();

Object ret = buf[--current]; afterGet = false;

public synchronized Object _get() throws Exception { while (current <= 0) wait();

Object ret = buf[--current]; afterGet = true;

(26)

History Buffer, again

public class _{HistoryBuffer} extends _Buffer { boolean afterGet = false;

public HistoryBuffer(int max) { super(max); }

public synchronized Object _gget() throws Exception { while ( current <= 0 || afterGet) wait();

afterGet = false; return super._get(); }

public synchronized Object _get() throws Exception { Object o = super.get();

afterGet = true; return o;

}

public synchronized void put(Object v) throws Exception { super._put(v);

(27)

Modification of Acceptable States

Anomaly when

_{mix-in classes}

are used to add behaviour to object via multiple inheritance.

class Lock { ...

void lock() { ...; } void unlock() { ...; } }

Trying to influence the enabling conditions of a class, by inheritance.

class LockableBuffer extends Buffer, Lock{ } Of course, this does no much towards having a

lockable buffer, in any language I know of.

(28)

Modification of Acceptable States

Anomaly when

_{mix-in classes}

are used to add behaviour to object via multiple inheritance.

class Lock { ...

void lock() { ...; } void unlock() { ...; } }

Trying to influence the enabling conditions of a class, by inheritance.

class LockableBuffer extends Buffer, Lock{ }

Of course, this does no much towards having a lockable buffer, in any language I know of.

(29)

JEEG

Jeeg

tackles the (_{History-Sensitive}) _{Inheritance Anomaly}. It is:

an _{aspect-oriented} superimposition of two separate languages

Java

(no _{synchronized()}, _wait(), _notify(), and _notifyAll() for _{business code});

Linear Time Temporal Logic

for _{synchronisation} code (method guards). public class _MyClass {

sync { m : φ; .... }

...// Standard Java class definition }

m is a method id and φ, the

_guard

, is a formula in a given

_constraint

language. When m is invoked, the thread is

_{kept on hold}

unless φ. When the condition is true, all

_waiting

threads are

_awaken

. m is implicitly

_synchronized

.

(30)

JEEG

Jeeg

Java

Linear Time Temporal Logic

for _{synchronisation} code (method guards).

public class _MyClass {

sync { m : φ; .... }

(31)

JEEG

Jeeg

Java

Linear Time Temporal Logic

for _{synchronisation} code (method guards).

public class _MyClass {

sync { m : φ; .... }

(32)

The logic

Logic

: a trade-off between

_{expressiveness}

and

_efficiency

: its formulae must be verified at every method invocation!

Linear temporal logic

(_{past tense})

φ ::= AP | !φ | φ || φ | Previous φ | φ Since φ

AP are _pure boolean expressions with no:

side-effects

,

references to objects

.

method invocations

,

and it only refers to

_{private/protected}

fields of the class it belongs to.

Derived connectives

:

φ && ψ ,!(!φ ||!ψ); Sometime φ , true Since φ; Always φ , !Sometime !φ.

(33)

The logic

Logic

_{expressiveness}

and

_efficiency

Linear temporal logic

(_{past tense})

side-effects

,

references to objects

.

method invocations

,

_{private/protected}

Derived connectives

:

φ && ψ ,!(!φ ||!ψ); Sometime φ , true Since φ; Always φ , !Sometime !φ.

(34)

The logic

Logic

_{expressiveness}

and

_efficiency

Linear temporal logic

(_{past tense})

side-effects

,

references to objects

.

method invocations

,

_{private/protected}

(35)

An Object’s History

A generic computation π from o’s perspective.

h00 · · ·h 0

j0o.m1h

1

0 · · · h 1

j1o.m2h

2

0 · · ·h 2

j2 . . .

Here only the part of hk_j_k containing the values of private/protected, non-reference variables of o, say σ_k, can affect evaluation. Therefore, we take

Ho(π) ≡ σ0

m1

→ σ1

m2

→ σ2

m3

→ σ3 . . .

We think of Ho(π) as

Ho ≡ σ0σ1σ2σ3 . . .

where σi binds the special identifier event to (a value representing method) mi.

(36)

An Object’s History

h00 · · ·h 0

j0o.m1h

1

0 · · · h 1

j1o.m2h

2

0 · · ·h 2

j2 . . .

Ho(π) ≡ σ0

m1

→ σ1

m2

→ σ2

m3

→ σ3 . . .

Ho ≡ σ0σ1σ2σ3 . . .

(37)

An Object’s History

h00 · · ·h 0

j0o.m1h

1

0 · · · h 1

j1o.m2h

2

0 · · ·h 2

j2 . . .

Ho(π) ≡ σ0

m1

→ σ1

m2

→ σ2

m3

→ σ3 . . .

Ho ≡ σ0σ1σ2σ3 . . .

(38)

Concurrent Objects’ Histories

n = 2

inc ()

n = 0 n = 1 n = 0

inc () dec ()

n = 0 inc () n = 1

C1

C2

C1

n = 0

C1

n = 1

C1

n = 2

C2

n = 0 C1

n = 1

C2

n = 0 C1

n = 1

C2

n = 1 C1

n = 1

C2

(39)

Interpretation of Formulae on Object Histories

Let Σ denote Ho(π). For all indexes k in Σ, we define Σk |= φ, that is φ holds at time k, by structural induction on φ as follows.

Σk |= p iff σk |= p (p is true at σk)

Σk |= !φ iff not Σk |= φ

Σk |= φ || ψ iff Σk |= φ or Σk |= ψ

Σk |= Previous φ iff k > 0 and Σk−1 |= φ

Σk |= φ Since ψ iff Σj |= ψ for some j ≤ k,

(40)

Buffer in JEEG

public class _Buffer { sync {

put : current < MAX;

get : current > 0; }

protected Object[] buf;

protected int MAX, current = 0;

Buffer(int max) {

MAX = max; buf = new Object[MAX]; }

public Object _get() throws Exception { Object ret = buf[--current];

return ret; }

(41)

History Buffer in JEEG

public class _{HistoryBuffer} extends _Buffer { sync {

gget: Previous (event != get) && current > 0; }

public _{HistoryBuffer}(int max) { super(max);

}

public Object _gget() throws Exception { Object ret = buf[--current];

return ret; }

(42)

Lockable Buffer in JEEG

public interface _Lock { public void _lock(); public void unlock(); }

public class _LockBuf extends _Buffer implements _Lock { sync {

get : super.getConstr && !Previous (event == _lock);

put : super.putConstr && !Previous (event == _lock);

lock : !Previous (event == _lock);

unlock : true; }

public _LockBuf(int max) { super(max); } public void lock() { }

(43)

Expressiveness of JEEG

It is generally hard to formalise to what extent the anomaly is removed. Nicely,

_Jeeg

allows for a

_{“quantitative”}

analysis.

Expressiveness of LTL

: A set of _{state sequences} X is the set of all Σs that _satisfy a given φ if and only if X is a _{star-free regular} language. (_{Zuck [1986]})

Star-free Regular Languages

:

re ::= ² | a | re · re | re + re | ¬r (| re∗)

State for

: p ∈ AC ⊂ AP;

Sequence of states

: P ∈ A∗_C. (Σ |= P iff

Σk |= Pk)

Theorem

(Characterizing CL). For φ a formula on C, X = {Σ | Σ |= φ} _iff

there exists re on A_C such that Σ ∈ X iff Σ |= P for some P ∈ re.

Special case

: Only _{atomic propositions} of the kind event == _m.

(44)

Expressiveness of JEEG

_Jeeg

allows for a

_{“quantitative”}

analysis.

Expressiveness of LTL

Star-free Regular Languages

:

re ::= ² | a | re · re | re + re | ¬r (| re∗)

State for

: p ∈ AC ⊂ AP;

Sequence of states

: P ∈ A_C∗. (Σ |= P iff Σk |= Pk)

Theorem

there exists re on AC such that Σ ∈ X iff Σ |= P for some P ∈ re.

Special case

(45)

Expressiveness of JEEG

_Jeeg

allows for a

_{“quantitative”}

analysis.

Expressiveness of LTL

Star-free Regular Languages

:

re ::= ² | a | re · re | re + re | ¬r (| re∗)

State for

: p ∈ AC ⊂ AP;

Sequence of states

: P ∈ A_C∗. (Σ |= P iff Σk |= Pk)

Theorem

Special case

(46)

Expressiveness of JEEG

_Jeeg

allows for a

_{“quantitative”}

analysis.

Expressiveness of LTL

Star-free Regular Languages

:

re ::= ² | a | re · re | re + re | ¬r (| re∗)

State for

: p ∈ AC ⊂ AP;

Sequence of states

: P ∈ A_C∗. (Σ |= P iff Σk |= Pk)

Theorem

Special case

(47)

Examples

HistoryBuffer

: the temporal constraint

Previous event != _get

can be expressed by the following star-free regular expressions.

¬(A∗ · get) where A∗ , ² + ¬².

The temporal constraint

Sometime m , true Since m.

corresponds to

(48)

Limitations of LTL: No Counting

public class _{SharedResource} { sync {

request: true;

release: true; }

public void _request() { ... } public void release() { ... } ...

}

Define a class

_{SeizableResource}

which allows _{exclusive access} to the shared resource: An additional method

_{exclusiveRequest}

must be provided.

Clearly, this leads to identify a pattern of events such as:

M ::= ² | request M release | MM | ...

(49)

Runtime Evaluation of CL Expressions

Given a finite trace Σ _{and a LTL formula} φ_{, does} Σ |= φ _?

Traditionally: build a

_{Buchi automata}

to ‘model-check’ sequences. Dealing with past tense operators gives us an advantage: an ‘

_online

’ algorithm.

Build the _{syntax tree} of the formula;

Associate variables _before and _now to every node, initially set to false; Visit the tree depth-first and simultaneously assign φ.before := φ.now and

φ.now as follows.

previous now := φ0.before

since now := φ1.now or (before and φ0.now)

or now := φ0.now or φ1.now

not now := not φ0.now

AP now := eval(φ)

(50)

Runtime Evaluation of CL Expressions

Given a finite trace Σ _{and a LTL formula} φ_{, does} Σ |= φ _?

Traditionally: build a

_{Buchi automata}

to ‘model-check’ sequences. Dealing with past tense operators gives us an advantage: an ‘

_online

’ algorithm.

Build the _{syntax tree} of the formula;

Associate variables _before and _now to every node, initially set to false; Visit the tree depth-first and simultaneously assign φ.before := φ.now and

φ.now as follows.

previous now := φ0.before

since now := φ1.now or (before and φ0.now)

or now := φ0.now or φ1.now

not now := not φ0.now

AP now := eval(φ)

(/).*-+,

φ1 : : : : : : :

φ0 ¥¥¥¥

¥¥¥

before, now

(/).*-+,

φ

before, now

(/).*-+,

φ

(51)

An Example

Example

: Let us consider the evaluation of the temporal formula

Previous(x == 1)

x = 0

inc ()

x = 1

inc ()

x == 1

now = true before = false

x == 1

now = false before = true

x = 2

dec ()

x = 1

x == 1

(52)

The Synchronisation Manager

Formulae must be evaluated after _every method execution. This is done by a

synchronization manager

via

_{Method Call Interception}

. It

takes control at method call and _checks (not _evaluates) the constraint for the method.

If it holds, control goes to the method code; otherwise the synchronization manager performs a _wait(), putting the object to _sleep.

After the method execution, control _{shifts back} to the manager, which now re-evaluates the synchronization constraints.

After updating the formulae logic value, the manager issues a _notifyAll() statement. Blocked methods may then attempt to proceed again.

(53)

Benchmarks: Object Creation

0 20 40 60 80 100 120 140 160 180

0 50 100 150 200

Constraint Size

Time in ms

Machine 3

Machine 2

Machine 4

(54)

Benchmarks: Method Call

0 20 40 60 80 100 120 140 160

Time in ms

Machine 1

Machine 2

Machine 3

(55)

Benchmarks: Details of Method Call

1 30 50 73 122 1 2 4 8 16 32 64 0 200 400 600 800 1000 1200

Time in ms

Constraint Size Threads

Machine 2 Machine 3

1 30 50 73 122 1 2 4 8 16 32 64 0 200 400 600 800 1000 1200 1400 1600

Time in ms

Constraint Size Threads

(56)

Benchmarks: Comparison

0 20 40 60 80 100 120 140

0 50 100 150 200 250

Threads

Time in ms

Machine 3

(57)

Performance Evaluation

Testing

shows that:

Under

_low-load

(below 70 threads) even complex synchronization constraints yield _{little performance overhead}.

(58)

Conclusion

Jeeg

Synchronization constraints written in _LTL and specified in a _{aspect-oriented}, declarative manner.

CL is helpful in treating the inheritance anomaly.

Characterisation of CL in terms of regular languages

Efficiently implementable (available at http://www.brics.dk/~milicia/Jeeg).

Future Work

:

Quantified linear temporal logic (_QLTL) or monadic second order logic (_MSOL), ‘second order’ variations of LTL of greater expressiveness.

(59)

Conclusion

Jeeg

Synchronization constraints written in _LTL and specified in a _{aspect-oriented}, declarative manner.

CL is helpful in treating the inheritance anomaly.

Characterisation of CL in terms of regular languages

Efficiently implementable (available at http://www.brics.dk/~milicia/Jeeg).

Future Work

:

Quantified linear temporal logic (_QLTL) or monadic second order logic (_MSOL), ‘second order’ variations of LTL of greater expressiveness.

Temporal Constraints for Concurrent Object Synchronisation (talk)

Full text