0% found this document useful (0 votes)
98 views23 pages

A Simple Abstraction For Complex Concurrent Indexes

This document presents a simple abstraction for specifying concurrent indexes. It defines concurrent abstract predicates to represent the mapping of keys to values in an index and the operations of search, insert and remove. This allows reasoning about concurrent programs that use indexes. The specification supports shared keys and provides proofs for implementations like concurrent B-trees. Future work includes automating proofs and applying the approach to other concurrent data structures and systems like file systems.

Uploaded by

Andrei Badoi
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
98 views23 pages

A Simple Abstraction For Complex Concurrent Indexes

This document presents a simple abstraction for specifying concurrent indexes. It defines concurrent abstract predicates to represent the mapping of keys to values in an index and the operations of search, insert and remove. This allows reasoning about concurrent programs that use indexes. The specification supports shared keys and provides proofs for implementations like concurrent B-trees. Future work includes automating proofs and applying the approach to other concurrent data structures and systems like file systems.

Uploaded by

Andrei Badoi
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 23

A Simple Abstraction for Complex Concurrent Indexes

OOPSLA 2011
Imperial College London: Pedro da Rocha Pinto, Thomas Dinsdale-Young, Philippa Gardner and Mark Wheelhouse University of Cambridge: Mike Dodds

Motivation
Indexes are ubiquitous in computing systems:

And have a variety of implementations:

Intuitive Index Specification


An index is a partial function mapping keys to values:


There are three basic operations on an index : r search(h,k) insert(h,k,v) remove(h,k)

Simple Concurrent Example

This intuitive specification is not enough to reason about concurrent access to the index. e.g r search(h,k); insert(h,k1,r) || remove(h,k2)

with k1 k2

Disjoint Key Concurrency


Concurrent Abstract Predicates:

, , : there is a mapping in the index from to , and only the thread holding the predicate can modify .
, : there is no mapping in the index from , and only the thread holding the predicate can modify . Axioms:
e.g.

, , ,

Concurrent Index Specification


, , * (, ) + * (, , ) + * (, ) + * (, , ) + * (, ) + r search(h,k) r search(h,k) insert(h,k,v) insert(h,k,v) remove(h,k) remove(h,k) * (, , ) = + * (, ) = + * (, , ) + * (, , ) + * (, ) + * (, ) +

Simple Concurrent Example

, 1 (, 2 , ) r search(h,k); * , 1 (, 2 , ) = + , 1 = insert(h,k1,r) * (, 1 , ) +

(, 2 , ) remove(h,k2) * (, 2 ) +

, 1 , , 2

More Example Programs

However, we still cannot reason about the following programs:

remove(h,k) insert(h,k,v) r search(h,k)

|| || ||

remove(h,k) remove(h,k) remove(h,k)

We need to account for the sharing of keys between threads.

Real-World Client Programs


Database sanitation: remove all patients who have been cured, transferred or released Graphics drawing: clip all objects outside of some horizontal and vertical bounds Garbage collection: parallel marking in the mark/sweep algorithm Web caching (NOSQL): removing a picture whilst others are attaching comments to it

Shared Key Concurrency


Extended Concurrent Abstract Predicates: with (0,1] (, , ) : the key definitely maps to value 0 < 1 : no other thread can change the value at key = 1 : this thread can change the value at key

is analogous

Shared Key Concurrency


Extended Concurrent Abstract Predicates: with (0,1] (, , ) : the key might map to a value, and if it does that value is 0 < 1 : all threads can only remove the value at key k, the current thread has not done this so far

is analogous

Similarly we have and for insert only

Concurrent Index Specification

New specification of remove(h,k):


, ,
1

remove(h,k) * ,

* , + remove(h,k) * , +
, , ,

remove(h,k) * , +

Concurrent remove
(, , )1 (, , )1 , , 0.5 (, , )0.5
0.5

, ,
,

, ,

0.5

remove(h,k)
0.5

remove(h,k)

0.5

, 0.5 , (, )1

0.5

Parallel Sieve of Eratosthenes

Parallel Sieve of Eratosthenes


Worker thread: * 2 2 , , 0 + worker(v,max,h) c v + v; while(c max) remove(h,c); c c + v; , , 2 (, ) (, , 0)

Combining Predicates

(, , ) (, , ) (, , )+ if + 1

(, , ) (, ) (, )+

if + 1

Parallel Sieve of Eratosthenes

Sieve specification: * 2 , , 0
1

> 1 +

worker(2,max,h)|| worker(3,max,h) || || worker(m,max,h) , , 0 1 2 () (, )1

where m =

Implementing a Concurrent Index

Our abstract concurrent index specification is sound for a number of different implementations, including:

Concurrent B-tree

9 - 44

3 - 22 38 44

8 44 66 71

1 - 4 10 20 22 22 L

2 22 37 38 38 L

7 38 40 42 44 44 L

4 44 52 62 66 66 L

6 66 68 71 71 L

5 71 77 85 93 L

Concurrent B-tree
B-tree remove implementation must satisfy the specification: , ,
1

remove(h,k) * ,

Concrete definition of (, , ) :
Shared state Interference environment
,
,

(, , ) = . , ,
RE M 0, k

LO C K

SW A P

IN S (0, k, v)
Capability tokens

(,)

Concurrent B-tree

Check axioms: for example, (, , ) , , Check stability of predicates Check implementations satisfy abstract specifications

, ,

if + 1

Concurrent B-tree
Proof of remove implementation:

Conclusion
Summary: simple abstract spec for concurrent indexes essence of real-world client programs correct implementations linked lists hash tables concurrent B-trees proof structure lends itself to automation Future work: Automation/Proof Assistant (Dinsdale-Young) java.util.concurrent (da Rocha Pinto) File Systems (Ntzik)

You might also like