2009-07-30 20 views
1

In einem meiner letzten Antwort, habe ich ein theoretisches Semaphore Beispiel Beschränkung des Zugriffs auf Speicherressourcen:Deadlock auf einem einzelnen Java-Semaphor?

public static byte[] createArray(int size) throws InterruptedException { 
    semaphore.acquire(size); 
    return new byte[size]; 
} 
public static void releaseArray(byte[] array) { 
    semaphore.release(array.length); 
} 

Ich denke, das eine Quelle der Deadlock sein kann, wenn die Zuordnung Verschachtelung ist schlecht:

semaphore = new Sempaphore(30, true); 
// T1         T2 
//--------------------------   ---------------------- 
a1 = createArray(10);           // 20 
             a3 = createArray(10);  // 10 
a2 = createArray(15);           // wait 
             a4 = createArray(15);  // wait 
// ...        // ... 
releaseArray(a1);      releaseArray(a3); 
releaseArray(a2);      releaseArray(a4); 

Ist meine Beobachtung wahr? Wenn ja, wie kann ich diese Situation vermeiden (z. B. zeitgesteuertes Warten und Rollback)?

Antwort

2

Ja, mit Semaphore.tryAcquire(permits, timeout, timeUnit) wäre die sinnvolle Sache hier zu tun. Offensichtlich müssen Sie vorsichtig sein, um den Semaphor in einem finally Block freizugeben, um Lecks zu vermeiden ...

+0

Danke. Ich war mehr daran interessiert, wie der Rollback im Falle der Ausnahme funktioniert - im Beispielfall ist es einfach, einfach loslassen und zu Zeile 1 zurückkehren und es erneut versuchen. Aber ich fürchte, wenn die In-Thread-Zuordnung weiter entfernt ist (zum Beispiel eine teure Berechnung eingeschlossen), kann das auch nicht helfen. Vielleicht sollte ich zu einem grobkörnigeren Sperrschema zurückkehren? – akarnokd

+0

Sie müssten Details zu dem komplexeren Beispiel sagen, um es sicher zu sagen - aber ich denke, ein Ansatz besteht darin, alle * verwandten * Ressourcen zurückzusetzen und es erneut zu versuchen ... vielleicht jedes Mal weiter zurück zu rollen, um andere Aufgaben zuzulassen mehr Chance zum Abschluss. –