locality in concurrent data structures
Download
Skip this Video
Download Presentation
Locality in Concurrent Data Structures

Loading in 2 Seconds...

play fullscreen
1 / 27

Locality in Concurrent Data Structures - PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on

Locality in Concurrent Data Structures. Hagit Attiya Technion. Abstract Data Types (ADT). Abstract representation of data & set of methods ( operations ) for accessing it Signature Specification. data. Implementing High-Level ADT. From lower-level ADTs

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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
abstract data types adt
Abstract Data Types (ADT)

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

Signature

Specification

data

Locality @ BGU

implementing high level adt
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
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
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
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
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

< <

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
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
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
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
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
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
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
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
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
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
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
In Retrospect

Locality @ BGU

customized virtual locking
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
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
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

< < <

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
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

to the rescue dcas again
To the Rescue: DCAS Again
  • Use DCAS to lock equally colored nodes

Locality @ BGU

in treatment
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 happens1
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

ad