1 / 13

Verifying Two-Lock Concurrent Queue: Deadlocks and Race Conditions Analysis

This article presents an in-depth analysis of a Two-Lock Concurrent Queue implemented using Java PathFinder (JPF). It explores the verification process, focusing on identifying deadlocks and race conditions during simulations with multiple enqueuer and dequeuer threads. Key findings include the detection of a race condition affecting the queue's behavior and strategies to resolve deadlocks. The paper provides insights into the importance of synchronization in maintaining consistency and showcases configurations tested with JPF, alongside recommended practices to improve queue reliability.

sasson
Télécharger la présentation

Verifying Two-Lock Concurrent Queue: Deadlocks and Race Conditions Analysis

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Verifying a Two-LockConcurrent Queue Hussain Tinwala Fall 2007

  2. Overview • Simulation Review • Searching for Deadlocks • Race Conditions • Queue Verification

  3. Reviewing the Simulation

  4. Searching for Deadlocks (1) • JPF did not find errors… • Introduced a problem I faced during implementation with Dequeuer threads:

  5. Searching for Deadlocks (2)

  6. Searching for Deadlocks (3) gov.nasa.jpf.jvm.choice.ThreadChoiceFromSet {Thread-0,>Thread-1} Enqueuer.java:57 : synchronized(sim) Enqueuer.java:59 : sim.notifyAll(); ------------------------------------------------------ transition #47 thread: 1 gov.nasa.jpf.jvm.choice.ThreadChoiceFromSet {>Thread-0} Dequeuer.java:38 : synchronized (sim) Dequeuer.java:40 : sim.wait(); ====================================================== snapshot #1 thread index=1,name=Thread-0,status=WAITING, this=Dequeuer@246,priority=5,lockCount=1 waiting on: Simulator@232 call stack:at Dequeuer.run(Dequeuer.java:40) ====================================================== results error #1: gov.nasa.jpf.jvm.NotDeadlockedProperty \ "deadlock encountered: thread index=0,name=main,s..." Run Simulation with 1 Enqueuer, 1 Dequeuer and 1 node: jpf -c jpf.properties…

  7. Race Conditions (1) Two types: - Critical: different outcomes - Non-critical: eventual outcome of the program is the same modify Both are synchronized methods read

  8. Race Conditions (2) • prompt> jpf -c jpf.properties … • - Removed `synchronized’ • jpf with 1 Enqueuer and 1 Dequeuer --> no error • jpf with 1 Enqueuer and n Dequeuers --> no error • jpf with >1 Enqueuer --> error • Enqueuer threads use both methods • modifies a value • reads a value • Dequeuer threads only use `getNumEnqsLeft’ • reads a value • Potential for a race condition…

  9. Race Conditions (3) • name=Thread-1,status=RUNNING,this=Enqueuer@136,priority=5,lockCount=0 • at Simulator.getNumEnqsLeft(Simulator.java:57) • at Enqueuer.run(Enqueuer.java:52) • Name=Thread-2,status=RUNNING,this=Enqueuer@137,priority=5,lockCount=0 • owned locks:Simulator@232 (because method is synchronized) • at Simulator.decrementNumEnqsLeft(Simulator.java:53) • at Enqueuer.run(Enqueuer.java:51) • =========================================== results • error #1: gov.nasa.jpf.tools.PreciseRaceDetector "race for: "int Simulator.numEnqsLeft" Thread-1 and Thread-2...” • =========================================== results • error #1: RaceDetector "potential field race: Simulator@232.numEnqsLeft" So we have 2 Enqueuers - One is updating the value - The other is attempting to read it • Using JPF to detect race conditions: • Add to configuration file: • # listeners • jpf.listener=gov.nasa.jpf.tools.precise.PreciseRaceDetector • Running JPF with 2 Enqueuers and 1 Dequeuer • jpf -c jpf.properties…

  10. Race Conditions (4) • Adding `synchronized’ to the methods removes the race condition • Question: Do both methods need to be synchronized? • Yes: To get rid of the race condition • No: A race does not have to be bad • Synchronizing the method that modifies a value may be sufficient • Added `synchronized’ only to the decrementNumEnqsLeft method which is used by Enqueuer threads. • getNumEnqsLeft method left without `synchronized’ • Tested again: jpf -c jpf.properties …

  11. Race Conditions (5) • JPF finds no deadlocks or errors but it does find a race condition • But that is okay… it is a non-critical race condition • No matter what order the execution takes, there will always be AT LEAST one Enqueuer thread that will find • getNumEnqsLeft() == 0 • And so, it will be able to notify any waiting Dequeuer threads. • Overall Advantage: There is less blocking in the Enqueuer thread

  12. Verifying the Queue • Nodes are always inserted after the last node in the linked list • Nodes are always deleted from the beginning of the linked list • Head always points to the first node in the list • Tail always points to the last node in the list • Potential Approach: • Use a PropertyListener • Ex: QueuePropertyListener extends PropertyListenerAdapter • Then at each transition, verify the above mentioned properties

  13. Thank you Questions?

More Related