SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

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

sasson avatar
sasson
13 diapositives · 270 Views · Aug 20, 2014

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.

Verifying Two-Lock Concurrent Queue: Deadlocks and Race Conditions Analysis - slide 1
01 / 13Verifying Two-Lock Concurrent Queue: Deadlocks and Race Conditions Analysis
1 / 17

Télécharger la présentation

Verifying Two-Lock Concurrent Queue: Deadlocks and Race Conditions Analysis
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  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?