A Persistent Friedman Lock-Free Queue Maurice Herlihy for - - PowerPoint PPT Presentation

▶
a persistent
SMART_READER_LITE
LIVE PREVIEW

A Persistent Friedman Lock-Free Queue Maurice Herlihy for - - PowerPoint PPT Presentation

Dec 20, 2022 114 likes •379 views

1 Michal A Persistent Friedman Lock-Free Queue Maurice Herlihy for Non-Volatile Memory Virendra Marathe Erez Petrank NVMW 19 2 THIS TALK Non-Volatile Concurrent Data Byte-Addressable Structures Memory Platform &

slide-1
SLIDE 1

A Persistent Lock-Free Queue for Non-Volatile Memory

Michal Friedman Maurice Herlihy Virendra Marathe Erez Petrank

NVMW ‘19

1

slide-2
SLIDE 2

THIS TALK

Concurrent Data Structures Non-Volatile Byte-Addressable Memory

2

▸ Platform & Challenge ▸ Definitions ▸ Queue designs ▸ Evaluation

slide-3
SLIDE 3

PLATFORM - BEFORE

CPU & Registers High-Speed Cache Memory (RAM)

Upon a crash Cache and Memory content is lost

Hard Disk

3

slide-4
SLIDE 4

PLATFORM - AFTER

CPU & Registers High-Speed Cache Memory (RAM)

Non- Volatile Memory

Hard Disk

4

Upon a crash Cache content is lost

slide-5
SLIDE 5

OPPORTUNITY

Non- Volatile Memory

CPU & Registers High-Speed Cache

Instead of writing blocks to disk, make our normal data structures persistent!

5

slide-6
SLIDE 6

MAJOR PROBLEM: ORDERING NOT MAINTAINED

▸ Write x = 1 ▸ Write y = 1 ▸ Flush &x ▸ Flush &y


Cache Memory

Flush Eviction Due to implicit eviction: 
 Upon a crash, memory may contain y = 1 and x = 0.

O2 can follow up on O1, but only O2 is reflected in the memory.

Implicit eviction of y 6

slide-7
SLIDE 7

EXAMPLE

▸ Suppose everything has been written except for this one pointer ▸ If a crash occurs, the memory will contain:

Head Tail Head Tail

7

slide-8
SLIDE 8

CHALLENGE

Non- Volatile Memory

CPU & Registers High-Speed Cache

Challenge: make data persistent at minimal cost

Problem: Caches and registers are volatile.

▸ Usually don’t care what’s in the cache/memory ▸ Here we care! Flush some data to maintain consistency in memory ▸ Flushing is costly

8

slide-9
SLIDE 9

THE MODEL

▸ Main memory is non-volatile ▸ Caches and registers are volatile ▸ All threads crash together ▸ New threads are created to continue the execution

9

slide-10
SLIDE 10

NEXT

▸ Definitions ▸ The queue designs

  • Surprisingly many details and challenges

10

slide-11
SLIDE 11

LINEARIZABILITY

  • [HerlihyWing ’90]
  • Each method call should appear to take effect

instantaneously at some moment between its invocation and response

11 Thread 1 q.enq(5) time Thread 2 q.enq(1) q.deq()=5 Thread 1 q.enq(5) time Thread 2 q.enq(1) q.deq()=1

slide-12
SLIDE 12

CORRECTNESS FOR NVM

12

Buffered Durable Linearizability Durable Linearizability

Detectable Execution

< <

Strength

1 2 3

Consistent state

[IzraelevitzMendesScott ’16] [IzraelevitzMendesScott ’16] [FHerlihyMarathePetrank ’18]

slide-13
SLIDE 13

DURABLE LINEARIZABILITY

13 Thread 1 Thread 2 q.enq(5) q.enq(1) q.deq=(1) q.deq=(1) q.deq=(5) time

▸ [IzraelevitzMendesScott ’16]

  • Operations completed before the crash are recoverable

(plus some overlapping operations)

  • Prefix of linearization order

Thread 1 Thread 2 q.enq(5) q.enq(1) q.deq=(5) time

< <

slide-14
SLIDE 14

DETECTABLE EXECUTION

▸ [FHerlihyMarathePetrank ’18]

  • Durable-linearizability - no ability to determine completion
  • Detectable execution extends durable linearizability:
  • Provide a mechanism to check if operation completed
  • Implementation example: a persistent log

14

< <

Thread 1 Thread 2 q.enq(5) q.enq(1) q.deq=(1) q.deq=(1) q.deq=(5) time

slide-15
SLIDE 15

▸ [IzraelevitzMendesScott ’16]

  • Some prefix of a linearization ordering
  • Support: a “sync” persists all previous operations

BUFFERED DURABLE LINEARIZABILITY

Thread 1 q.enq(5) time Thread 2 q.enq(1) q.deq=(1) q.deq=(5

Sync

15 Thread 1 q.enq(5) time Thread 2

< <

slide-16
SLIDE 16

THREE NEW QUEUE DESIGNS

▸ Three lock-free queues for non-volatile memory

[FHerlihyMarathePetrank ’18] Durable Relaxed Log

Durable + can tell if an

  • peration

recovered (Detectable) A prefix of executed

  • perations is

recovered (Buffered)

▸ Design ▸ Evaluation

16

< <

All operations completed before the crash are recovered (Durable)

▸ Based on lock-free queue [MichaelScott ’96]

slide-17
SLIDE 17

MICHAEL AND SCOTT’S QUEUE (BASELINE)

▸ A Lock-Free queue ▸ The base algorithm for the queue in java.util.concurrent ▸ A common simple data structure, but ▸ Complicated enough to demonstrate the challenges

Head Tail

Data Data Data Data

17

slide-18
SLIDE 18

ENQUEUE

Head Tail

Data

Data

Data

Data

x

Data

▸ Enqueue (data):

  • 1. Allocate a node with its values.
  • 2. Read tail and tail->next values.
  • 3. Insert node to queue - CAS last pointer ptr point to it.

4.Update tail. 1.a. Flush node content to memory. (Initialization guideline.)

3.a. Flush ptr to memory. (Completion guideline.)

2.a. Help: Update tail.

18

ENQUEUE DURABLE

volatile non-volatile

< <

slide-19
SLIDE 19

Head Tail

Data

Data

Data

Data

x

Data

19

ENQUEUE - MORE COMPLEX DURABLE

▸ Enqueue (data):

  • 1. Allocate a node with its values.
  • 2. Read tail and tail->next values.
  • 3. Insert node to queue - CAS last pointer ptr point to it.

4.Update tail. 1.a. Flush node content to memory. (Initialization guideline.)

3.a. Flush ptr to memory. (Completion guideline.)

2.a. Help: Update tail.

For example, if this CAS fails due to concurrent activity, we need to be careful to maintain durable linearizability…

volatile non-volatile

slide-20
SLIDE 20

▸ Enqueue (data):

  • 1. Allocate a node with its values.
  • 2. Read tail and tail->next values.
  • 3. Insert node to queue - CAS last pointer ptr point to it.

4.Update tail. 1.a. Flush node content to memory.

3.a. Flush ptr to memory.

2.a. Help: Update tail.

Head Tail

Data Data Data Data

x

Fail

y

Data

20

ENQUEUE - MORE COMPLEX DURABLE

Tail

slide-21
SLIDE 21

Head Tail

Data Data Data Data

x

Fail

y

Data ▸ Enqueue (data):

  • 1. Allocate a node with its values.
  • 2. Read tail and tail->next values.
  • 3. Insert node to queue - CAS last pointer ptr point to it.

4.Update tail.

1.a. Flush node content to memory.

3.a. Flush ptr to memory. (Completion

2.a. Help: Update tail.

▸ Complete (and persist) previous operation:

  • 5. Flush ptr to memory.

6.Update tail.

21

ENQUEUE - MORE COMPLEX DURABLE

slide-22
SLIDE 22

RELAXED QUEUE

▸ Buffered Durable

linearizable

▸ Challenge 1: Obtain

snapshot at sync() time

▸ Challenge 2: Making sync()

concurrent

LOG QUEUE

▸ Durable linearizable ▸ Detectable execution ▸ Log operations ▸ More complicated

dependencies and recovery

22

slide-23
SLIDE 23

EVALUATION

▸ Compare the three queues: durable, relaxed, log and

Michael and Scott’s queue

▸ Platform: 4 AMD Opteron(TM) 6376 2.3GHz processors,

64 cores in total , Ubuntu 14.04.

▸ Workload: threads run enqueue-dequeue pairs

concurrently

23

slide-24
SLIDE 24

Durability & detectable costly. Similar overhead Buffered durability less costly

EVALUATION - THROUGHPUT

24

Michael and Scott’s - baseline Durable (durable linearizable) Log (detectable) Relaxed - frequent “sync” Relaxed - between in/frequent Relaxed - infrequent “sync” Implementation details:

  • Frequent sync: every 10 ops/thread
  • Infrequent sync: every 1000 ops/thread
  • Queue initial size: 1 M

Operations/Sec [Millions]

Persistent

Not persistent

slide-25
SLIDE 25

CONCLUSION

▸ A variant of durable linearizability: detectable execution ▸ Three lock-free queues for NVM: Relaxed, Durable, Log ▸ Guidelines ▸ Evaluation

  • Durability and detectability -

similar overhead

  • Buffered durability is less costly

25