- By
**macon** - Follow User

- 120 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about ' Locality in Concurrent Data Structures' - macon

**An Image/Link below is provided (as is) to download presentation**

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

### Locality in Concurrent Data Structures

Hagit AttiyaTechnion

Abstract Data Types (ADT)

Abstract representation of data& set of methods (operations) for accessing it

Signature

Specification

data

Locality @ BGU

Implementing High-Level ADT

From lower-level ADTs

High-level operations translate into primitives on base objects

Obvious: read, write

Common: compare&swap (CAS), LL/SC,

Double-CAS (DCAS),

Generic: read-modify-write (RMW), kRMW, kCAS, …

Low-level operations can be implemented from more primitive operations

A hierarchy of implementations

Locality @ BGU

Example: Binary Operations

Atomically read and modify two memory locations (esp. DCAS)

- Simplify the writing of concurrent ADTs
- kCAS is even better

Virtual Locking: Simulate DCAS / kCAS with a single-item CAS

- Acquire virtual locks on nodes in the data set
- Perhaps in some order
- Handle conflicts with blocking operations (holding a required data item)

Locality @ BGU

Virtual locking

[Turek, Shasha, Prakash, 1992] [Barnes]

- Acquire locks by increasing addresses
- Guarantees that the implementation is nonblocking
- Help the blocking operation to complete (recursively)
- May result in long helping chains

Locality @ BGU

Virtual Locking: Reducing Contention

[Shavit, Touitou, 1995]

- Release locks when the operation is blocked
- Help an immediate neighbor (only) & retry…
- Short helping chains
- But long delay chains

Locality @ BGU

Randomization: How Often this Happens?

[Ha, Tsigas, Wattenhofer, Wattenhofer, 2005]

- Operations choose locking order at random
- Chains’ length depends on log n / loglog n
- Also experimentally
- Better, and yet…
- Similar analysis for chains’ length when ops choose items at random
- Depends on the operations’ density

[Dragojevic, Guerraoui & Kapalka, 2008]

Locality @ BGU

Color-Based Virtual Locking (Binary)

[Attiya, Dagan, 1996]

- Operations on two data items (e.g., DCAS)
- Colors define the locking order
- Inspired by the left-right dinning philosophers algorithm

[Lynch, 1980]

- Color the items when the operation starts
- Non-trivial… [Cole, Vishkin, 1986]
- Bound the length of delay chains
- But the coloring stage is complicated

Locality @ BGU

Color-Based Virtual Locking (Fixed k)

[Afek, Merritt, Taubenfeld, Touitou, 1997]

- Implements operations on k items, for a fixedk
- Based on the memory addresses, the conflict graph is decomposed into trees & items are legally colored [Goldberg, Plotkin, Shannon]
- Need to have the data set from the beginning
- Recursive, with A&D at the basis and in each step
- Even more complicated

Locality @ BGU

Virtual Locking: More Concurrency, Simpler

[Attiya, Hillel, 2008]

- Acquire locks in arbitrary order
- No need to know the data set (or its size) in advance
- No pre-computation

Possible ways to handle conflicts between operations contending for a data item

- Wait for the other operation
- Help the other operation
- Reset the other operation

Locality @ BGU

Conflict Resolution, How?

Depends on the operations’ progress

More advanced operation wins

- How to gauge progress?
- What to do on a tie?

Locality @ BGU

Who’s More Advanced?

- The operation that locked more data items
- If a less advanced operation needs an item
- help the conflicting operation or
- wait (blocking in a limited radius)
- If a more advanced operation needs an item
- reset the conflicting operation and claim the item

Locality @ BGU

What about Ties?

2

2

Happen when two transactions locked the same number of items

A transaction has a descriptorand a lock

Use DCAS to race for locking the two descriptors

- Winner calls the shots…

Locality @ BGU

Measuring Concurrency:Data Items and Operations

A data structure is a collection of items

An operation accesses a data set

not necessarily a pair

A set of operations induces a conflict graph

Nodes represent items

Edges connect items of the same operation

Locality @ BGU

Spatial Relations between Operations

Disjoint access

Non adjacent edges

Distance is infinite

Overlapping operations

Adjacent edges

Distance is 0

Chains of operations

Paths

Distance is length of path (here, 2)

d-neighborhood of an operation: all operations at distance ≤ d

Locality @ BGU

Interference between Operations

Disjoint access

Overlapping operations

Non-overlapping operations

Provides more concurrency & yields better throughput

Interference inevitable

Should not interfere!

no interference

Locality @ BGU

Measuring Concurrency: Locality

d failure locality[Choi, Singh, 1992] some operation completes in the d-neighborhood unless a failure occurs in the d-neighborhood

d-local nonblockingsome operation completes in the d-neighborhood even if a failure occurs in the d-neighborhood

17

Locality @ BGU

Quantitative Measures of Locality

[Afek, Merritt, Taubenfeld, Touitou, 1997]

Distance in the conflict graph between overlapping operations that interfere

d-local step complexity: Only operations at distance ≤ d delay each other

d-local contention: Only operations at distance ≤ d access the same memory location

18

Locality @ BGU

In Retrospect

Locality @ BGU

Customized Virtual Locking

- Can be viewed as software transactional memory
- High overhead
- Or handled by specialized algorithms
- Ad-hoc and very delicate, mistakes happen
- Instead, design algorithms in a systematic manner…
- Lock the items that have to be changed & apply a sequential implementation on these items
- Lock items by colors to increase concurrency
- No need to re-color at the start of each operations since with a specific data structure
- We manage a data structure since its infancy
- The data sets of operations are predictable

Locality @ BGU

Example: Doubly-Linked Lists

- An important special case underlying many distributed data structures
- E.g., priority queue is used as job queue
- Insert and Remove operations
- Sometimes only at the ends (deques)
- The data set is an item and its left / right neighbors (or left / right anchor)

Locality @ BGU

Built-In Coloring for Doubly-Linked Lists

- An important special case underlying many distributed data structures
- E.g., priority queue is used as job queue
- Insert and Remove operations
- Sometimes only at the ends (deques)
- The data set is an item and its left / right neighbors (or left / right anchor)

[Attiya, Hillel, 2006]

- Always maintain the list items legally colored
- Adjacent items have different colors
- Adjust colors when inserting or removing items
- No need to color from scratch in each operation!
- Constant locality: operations that access disjoint data sets do not delay each other

Locality @ BGU

Insert Operation

- New items are assigned a temporary color
- Remove from the ends is similar to Insert
- Locks three items, one of them an anchor

new

item

Locality @ BGU

Removing from the Middle

- Complicated: Need to lock three list items
- Possibly two with same color
- A chain of Remove operations may lead to a long delay chain in a symmetric situation

Locality @ BGU

In Treatment

- DCAS???
- Supported in hardware, or at least with hardware transactional memory
- Software implementation (e.g., A&D)
- Software transactional memory?!
- Speculative execution
- Read accesses
- Blocking?!!!
- Not so bad w/ low failure locality
- Can be translated to nonblocking locality

Locality @ BGU

Randomization: How Often this Happens?

[Ha, Tsigas, Wattenhofer, Wattenhofer, 2005]

- Operations choose locking order at random
- Chains’ length depends on log n / loglog n
- better, and yet…
- Similar analysis for chains’ length when ops choose items at random
- Depends on the operations’ density

[Dragojevic, Guerraoui & Kapalka, 2008]

Locality @ BGU

Download Presentation

Connecting to Server..