Reactive Shared Objects for Interprocess Synchronization

1
Reactive Shared Objects for Interprocess
Synchronization

• Phuong Hoai Ha

Seminar for the Degree of Licentiate of
Philosophy Department of Computing
Science October 18th 2004, Gothenburg, Sweden.
2
Schedule

• Introduction
• Coordinating Objects
• Reactive Shared Objects
• Reactive Multi-word Synchronization
• Algorithms
• Evaluation
• Self-tuning Reactive Trees
• Algorithms
• Evaluation
• Conclusions Future Work

3
What are coordinating objects?
Coordination
?
?
?
high collision!
high load!
?
?
?

• Data structures that evenly distribute processes
  into small groups, which each accesses different
  shared objects in a coordinated manner.

4
Example Diffracting trees
B2
A0
B1
C6
B1
A
B,
F, E, D, C,
B3
5
Schedule

• Introduction
• Coordinating Objects
• Reactive Shared Objects
• Reactive Multi-word Synchronization
• Algorithms
• Evaluation
• Self-tuning Reactive Trees
• Algorithms
• Evaluation
• Conclusions Future Work

6
Why are reactive objects useful?
Snake queue

• Performance of concurrent objects heavily rely on
  their surrounding environment.
• Multiprogramming systems are unpredictable
• Interference among processes ? traffic on the
  bus/network, contention on memory modules, load
  on processors etc. are unpredictable.

?
?
?
?
?
?
?
Express queue
?
?
7
Example Reactive diffracting trees
A0
B1
B1
A
B,
F, E, D, C,
B3

• Challenges
• In multiprocessor systems, processors
  surrounding environment changes too fast compared
  with their reactions.
• Multiprogramming environments are unpredictable.

8
Schedule

• Introduction
• Coordinating Objects
• Reactive Shared Objects
• Reactive Multi-word Synchronization
• Algorithms
• Evaluation
• Self-tuning Reactive Trees
• Algorithms
• Evaluation
• Conclusions Future Work

9
Hardware or Software ?

• Programmers need high-level synchronization
  operations
• multi-word read-modify-write
• Hardware systems can support only a limited
  number of synchronization primitives
• single-word primitives

synchronization primitives
10
Multi-word compareswap Specifications

• CASN Atomic read-modify-write to a set of
  locations
• CASN( ( x1, a1, b1), ( x2, a2, b2), , ( xn,
  an,bn) )
• atomically
• if( ( x1 a1) ( xn an)) x1 b1
  xn bn return( true)
• else return( false)
• Useful building blocks in the implementations of
  concurrent data structures
• Many existing designs (queue, stack, linked list
  etc.) use CAS2 directly
• A higher abstraction like transactions is
  provided

11
Reactive CASN
CASNs
RCASN states
RCASN data structure
12
Reactive CASN illustration
? word
? conflict
?
?
?
?
?
?
?
?
?
?
13
First RCASN
When to move back?

• How to calculate the threshold?
• Mapping
• ri blockedi / kepti average contention
• blockedi ? 1, P-2, kepti ? 1, N-1
• Threshold r sqrt( (P-2) / (N-1))
• Competitive ratio c sqrt((P-2)(N-1))
• Advantages
• Reduce contentions
• Favor RCASNs
• close to completion
• causing a small number of conflicts

14
First RCASN illustration
4
5
3
6
7
8
2
1
...
words
?
O1( 1, 2, 3, 4)
help O2
O2( 3, 6, x, x)
Unlock? No!
help O3
O3( 6, 7, 8, x)
Unlock? Yes!
help O1
O4( 1, x, x, x)

• P4, N4 ? R sqrt( 2/3)

15
Second RCASN
When and how far to move back?
Rules (cf. threat-based algorithm)

• Advantages
• Reduce contentions
• Favor to release words with high contention.

16
Technical difficulties

• Requirements
• Non-blocking
• Atomicity
• No circle-helping
• Interference among CAS has not to affect the
  result
• Garbage collection

17
Previous works

• Static helping policies
• Recursive helping policy (RHP) selfishly keep
  acquired words
• Software transactional memory (STM) release all
  acquired words before helping

18
Results from our experiments
19
Schedule

• Introduction
• Coordinating Objects
• Reactive Shared Objects
• Reactive Multi-word Synchronization
• Algorithms
• Evaluation
• Self-tuning Reactive Trees
• Algorithms
• Evaluation
• Conclusions Future Work

20
Self-tuning trees

• Advantages
• No need of fixing manually any parameters
• Ability to shrink and expand many levels at one
  time
• Reasonable costs for adjustments.

21
Reactive policy

• Problem balancing the trade-off between two key
  measures, the contention level and the depth of
  the tree.

?
?
?
?
?
?
?
?
?
?
?
22
When to expand/shrink ?
Rules for expansion (cf. threat-based algorithm)

• Advantages
• Reduce contention keep traversal short
• Favor to expand leaves with high contention.
• Similar for shrinkage

23
Expanding a leaf to a subtree
IN
12
2
8
2 pending processors
10
6
24
Shrinking a subtree to a leaf

• Elect2Shrink check whether half the number of
  leaves in the subtree vote for the leaf
• Shrink

IN
8
12
3/4 ? shrink
4
6
5 active processors
2
25
Technical difficulties

• Requirements
• Non-blocking manners for balancers
• Correct output values
• Minimal disturbance for processors

26
Previous works

• Reactive diffracting trees (RD-tree)
• Require experimentally tuned parameters for each
  system
• Inefficient reactive scheme
• Shrink/expand one level in one adjustment step
• Costly adjustment

27
Results Full contention benchmark
28
Results Index distribution benchmark
29
Results Surge load benchmark
30
Schedule

• Introduction
• Coordinating Objects
• Reactive Shared Objects
• Reactive Multi-word Synchronization
• Algorithms
• Evaluation
• Self-tuning Reactive Trees
• Algorithms
• Evaluation
• Conclusions Future Work

31
Conclusions

• We have presented two reactive, lock-free
  multi-word compare-and-swap that
• Measure in an efficient way the contentions on
  the words,
• Reactively decide whether and how many words need
  to be released,
• Promote the CASN operations with high probability
  of success,
• Are competitive and run fast.
• We have presented a new data structure that
• Distributes a set of processors to many smaller
  groups accessing disjoint critical sections in a
  global coordinated manner.
• Collects information about the contention at the
  leaves and then adjusts itself to attain optimal
  performance without using any experimental
  parameters.

32
Future work

• Continue researching on reactive synchronization.
• Motivations
• Many reactive synchronization algorithms heavily
  rely on
• Tuned experimental parameters.
• Reactive diffracting trees, test-and-test-and-set
  with exponential back-off, etc.
• ? The fixed parameters cannot support good
  reactive schemes in dynamic environments such as
  multiprocessor systems (traffic on buses,
  contention on memory modules, load on processors
  etc.)
• Assumptions that some inputs follow known
  probability distributions
• ? Too strong assumptions generally, inputs in
  dynamic environments such as contention on memory
  modules are unpredictable.

33
Future work (cont.)

• Ideally, reactive algorithms should be able to
  observe the changes in the environment and react
  accordingly.
• Online algorithms and competitive analysis seem
  to be a promising direction.
• Look into new reactive schemes that allow faster
  reaction and better execution time
• Simplify/develop algorithms on specific problems
  in practice.

34
Thank you!