Semaphore Deadlock

[Jens81]

Hallo zusammen,

ich habe ein Deadlock-Problem. Ich nutze eine Semaphore zu Verwaltung einer Liste, der aus einem Thread Items hinzugefügt werden können, ein anderer Thread liefert den aktuellen Status der Einträge (wenn der User "aktualisieren" drückt). Jetzt kann es zum Deadlock kommen, wenn ein Job angelegt wird und der User gleichzeitig aktualisiert. Mir ist nur leider nicht klar warum???:L
Exception wird keine geworfen, die System.outs enden mit: "A" und "Sperre" -> Beide warten auf das release()

Ich habe folgende Methoden in "main":

public synchronized void addBatchjob(ItemBatchjob job) {
  try {
    System.out.println("A");
    batchjobcontroller.acquire();
    batchjobliste.add(job);
			
    OutputStream fos = new FileOutputStream("batchjobliste.crm"); 
    ObjectOutputStream o = new ObjectOutputStream(fos); 
    o.writeObject(batchjobliste);	
  } catch (Exception e) {
    e.printStackTrace();
  } finally {
    batchjobcontroller.release();
    System.out.println("R");
  }
}

public synchronized void sperreBatchjobliste() {
  try {
    System.out.println("Sperre");
    batchjobcontroller.acquire();  //batchjobcontroller: Binäre, faire Semaphore
  } catch (Exception e) {
    e.printStackTrace();
  }			
}

public synchronized void oeffneBatchjobliste() {
  try {
    System.out.println("Öffne");
    batchjobcontroller.release();
  } catch (Exception e) {
    e.printStackTrace();	
  }
}

Aktualisieren:

final DisabledGlassPane glass = new DisabledGlassPane();
JRootPane rootPane = SwingUtilities.getRootPane(fenster);
rootPane.setGlassPane(glass);
		
fenster.setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR));
glass.activate("Bitte warten...");

SwingWorker<Void, Void> worker = new SwingWorker<Void, Void>() {	
  @Override
  protected Void doInBackground() throws Exception {
    synchronized (this) {
      main.sperreBatchjobliste();
      aktualisiereStatus(model);
      main.oeffneBatchjobliste();
    }
				
    return null;
  }
			
  @Override
  protected void done() {
    glass.deactivate();
    fenster.setCursor(Cursor.getPredefinedCursor(Cursor.DEFAULT_CURSOR));
  }		
};
worker.execute();

Hinzufügen:

main.addBatchjob(new ItemBatchjob(...));

 

[Marco13]

Was auffällt ist, dass sowohl oeffneBatchJobDinges als auch sperreBatchJobDingens synchronized sind. Eigentlich sollte das doch nicht notwendig sein, oder?
Ansonsten wäre ein KSKB da sicher hilfreich.

 

[Jens81]

Ja, das ist mir beim durchgehen der einzelnen Programmteile auch aufgefallen Ich dachte, dass es im Zweifelsfall ja nicht schaden kann - aber so wie es im Moment ist, ist es überflüssig und evtl. sogar die Ursache des Locks (???:L). Ich teste z.Z. aber noch, da der Lock ja nur gelegentlich auftritt.

 

[Empire Phoenix]

In welchem Sinne äussert sich dein Deadlock?
Dabei sollte eigntlich gar keiner auftreten können, weil du keine zyklsiche wartebedingung hast, zumindest sehe ich keine.
Wie siht die Konsolenausgabe bei deinem Deadlock aus?

Ausserdem warum rufst du
batchjobcontroller.release();
auf wenn du dier dafür eine methode geschreibenh ast die das tut, ist unübersichtlich entweder direkt oder über methoden, nicht beides.

 

[Marco13]

An einzelnen Codestücken kann man die Ursache schwer erkennen - NOCH schwerer, als bei einem kompletten Programm, und selbst da ist es schon schwer genug Es ist nur z.B. immer gefährlich, wenn auf zwei Objekte synchronisiert wird (wie hier bei den beiden genannten Funktionen, die auch noch in einem synchronized-Block aufgerufen werden) - eigentlich nur, wenn die synchronisation unterschiedlich geschachtelt ist, wie

public void ab() 
{
    synchronized (a) 
    {
        synchronized (b) 
        { 
            bla();
        }
    }
}
public void ba() 
{
    synchronized (b) 
    {
        synchronized (a) 
        { 
            blubb();
        }
    }
}

aber hier kommt noch eine Semaphore dazu und so... ist hier halt schwer zu erkennen.

 

[FArt]

Schau dir den Thread-Dump zur Zeit des Deadlocks an und du wirst sehen wo der Hammer hängt.

 

[Jens81]

Es scheint wirklich an dem verschachtelten synchronized-Block gelegen zu haben. Danke für eure Hilfe