a persistent
play

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

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 &


  1. � 1 Michal A Persistent Friedman Lock-Free Queue Maurice Herlihy for Non-Volatile Memory Virendra Marathe Erez Petrank NVMW ‘19

  2. � 2 THIS TALK Non-Volatile Concurrent Data Byte-Addressable Structures Memory ▸ Platform & Challenge ▸ Definitions ▸ Queue designs ▸ Evaluation

  3. � 3 PLATFORM - BEFORE CPU & Registers Memory Hard Disk (RAM) High-Speed Cache Upon a crash Cache and Memory content is lost

  4. � 4 PLATFORM - AFTER CPU & Registers Memory Hard Disk (RAM) Non- Volatile Memory High-Speed Cache Upon a crash Cache content is lost

  5. � 5 OPPORTUNITY CPU & Registers Non- Volatile Memory High-Speed Cache Instead of writing blocks to disk, make our normal data structures persistent!

  6. � 6 MAJOR PROBLEM: ORDERING NOT MAINTAINED ▸ Write x = 1 Cache ▸ Write y = 1 Eviction Flush Implicit eviction of y ▸ Flush & x Memory ▸ Flush & y 
 Due to implicit eviction: 
 Upon a crash, memory may contain y = 1 and x = 0 . O 2 can follow up on O 1 , but only O 2 is reflected in the memory.

  7. � 7 EXAMPLE Head Tail ▸ Suppose everything has been written except for this one pointer ▸ If a crash occurs, the memory will contain: Head Tail

  8. � 8 CHALLENGE CPU & Registers Non- Volatile Challenge: make Memory High-Speed Cache 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

  9. � 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

  10. � 10 NEXT ▸ Definitions ▸ The queue designs • Surprisingly many details and challenges

  11. � 11 LINEARIZABILITY ‣ [HerlihyWing ’90] • Each method call should appear to take effect instantaneously at some moment between its invocation and response q.enq(5) q.enq(5) Thread 1 Thread 1 q.deq()=1 q.deq()=5 q.enq(1) q.enq(1) Thread 2 Thread 2 time time

  12. � 12 CORRECTNESS FOR NVM Consistent state 1 2 3 Detectable Buffered Durable < < Durable Linearizability Execution Linearizability [IzraelevitzMendesScott ’16] [IzraelevitzMendesScott ’16] [ F HerlihyMarathePetrank ’18] Strength

  13. < < � 13 DURABLE LINEARIZABILITY ▸ [IzraelevitzMendesScott ’16] • Operations completed before the crash are recoverable (plus some overlapping operations) • Prefix of linearization order q.enq(5) q.enq(5) Thread 1 Thread 1 q.deq=(1) q.deq=(1) q.deq=(5) q.deq=(5) q.enq(1) q.enq(1) Thread 2 Thread 2 time time

  14. < < DETECTABLE EXECUTION � 14 ▸ [ F HerlihyMarathePetrank ’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 q.enq(5) Thread 1 q.deq=(1) q.deq=(1) q.deq=(5) q.enq(1) Thread 2 time

  15. � 15 BUFFERED DURABLE LINEARIZABILITY < < ▸ [IzraelevitzMendesScott ’16] • Some prefix of a linearization ordering • Support: a “sync” persists all previous operations Sync q.enq(5) q.enq(5) Thread 1 Thread 1 q.deq=(1) q.enq(1) q.deq=(5 Thread 2 Thread 2 time time

  16. � 16 THREE NEW QUEUE DESIGNS ▸ Three lock-free queues for non-volatile memory [ F HerlihyMarathePetrank ’18] < < Relaxed Durable Log All operations A prefix of Durable + can completed executed tell if an before the crash operations is operation are recovered recovered recovered ( Durable ) ( Buffered ) ( Detectable ) ▸ Based on lock-free queue [MichaelScott ’96] ▸ Design ▸ Evaluation

  17. � 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

  18. ENQUEUE DURABLE ENQUEUE < < � 18 ▸ Enqueue (data): 1. Allocate a node with its values. 1.a. Flush node content to memory. ( Initialization guideline.) 2. Read tail and tail->next values. 2.a. Help: Update tail. 3. Insert node to queue - CAS last pointer ptr point to it. 3.a. Flush ptr to memory. ( Completion guideline.) x 4.Update tail . Head Tail Data Data Data Data Data volatile non-volatile

  19. DURABLE ENQUEUE - MORE COMPLEX � 19 ▸ Enqueue (data): For example, if this CAS fails due to concurrent 1. Allocate a node with its values. activity, we need to be careful to maintain durable linearizability… 1.a. Flush node content to memory. ( Initialization guideline.) 2. Read tail and tail->next values. 2.a. Help: Update tail. 3. Insert node to queue - CAS last pointer ptr point to it. 3.a. Flush ptr to memory. ( Completion guideline.) x 4.Update tail . Head Tail Data Data Data Data Data volatile non-volatile

  20. DURABLE ENQUEUE - MORE COMPLEX � 20 ▸ Enqueue (data): 1. Allocate a node with its values. 1.a. Flush node content to memory. 2. Read tail and tail->next values. 2.a. Help: Update tail. Tail 3. Insert node to queue - CAS last pointer ptr point to it. Fail 3.a. Flush ptr to memory. y x 4.Update tail . Data Data Head Tail Data Data Data

  21. DURABLE ENQUEUE - MORE COMPLEX � 21 ▸ Enqueue (data): 1. Allocate a node with its values. 1.a. Flush node content to memory. 2. Read tail and tail->next values. 2.a. Help: Update tail. 3. Insert node to queue - CAS last pointer ptr point to it. Fail 3.a. Flush ptr to memory. ( Completion Complete (and persist) previous operation: ▸ 4.Update tail . 5. Flush ptr to memory. 6. Update tail . y x Head Tail Data Data Data Data Data

  22. � 22 LOG QUEUE RELAXED QUEUE ▸ Durable linearizable ▸ Buffered Durable linearizable ▸ Detectable execution ▸ Challenge 1: Obtain ▸ Log operations snapshot at sync() time ▸ More complicated ▸ Challenge 2: Making sync() dependencies and concurrent recovery

  23. � 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

  24. � 24 EVALUATION - THROUGHPUT Operations/Sec [Millions] Michael and Scott’s - baseline Durable (durable linearizable) Not Log (detectable) persistent Relaxed - frequent “sync” Relaxed - between in/frequent Buffered Relaxed - infrequent “sync” durability less costly Persistent Durability & Implementation details: detectable costly. - Frequent sync: every 10 ops/thread Similar overhead - Infrequent sync: every 1000 ops/thread - Queue initial size: 1 M

  25. � 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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend