# Thread Synchronisation. mutex.lock(); und mutex.unlock();



## Happyman0815 (26. Jul 2009)

Hallo Leute!

Ich wunder mich gerade über das vorgehen meiner Thread Synchronisation mit kritischen Bereichen.


```
//Declaration
	final Lock mutex      = new ReentrantLock(); 
	final Lock mutex_recv = new ReentrantLock();



//Worüber ich mich wundere:

//     Folgendes "funktioniert":
	mutex.lock();
	mutex.lock();


  


//     Folgendes "funktioniert" nicht (exception):
	mutex.unlock();
	mutex.unlock();
```

So wie ich das sehe müsste er beim oben beim zweiten lock() hängen! Da er ja schon gelockt ist. Also ein Deadlock.

Beim unteren Beispiel wirft er eine Exception. (Beim zweiten .unlock() )



Dahrer => Warum funktioniert das oberer Beispiel, und warum gibt es beim unteren eine Exception?

Habe ich was nicht beachtet?

So wie ich das sehe ist die Exception berechtigt und beim zweiten lock() sollte er blockieren. Das tut er aber nicht. Daher ist der Sinn doch nicht erfüllt oder? In C++ verhält sich das irgendwie anders :bahnhof:



Gruß
Happyman0815


----------



## SlaterB (26. Jul 2009)

Deadlock wenn ein Thread auf sich selber wartet?
wann kann so eine Situation je Sinn machen? ist doch gut, dass es sowas nicht gibt, hier wird nur der HoldCount erhöht,
wie es übrigens auch in der Beschreibung der Methode steht,

bei 2x lock funktioniert dann auch 2x unlock ohne Exception


----------



## Happyman0815 (26. Jul 2009)

Achso!

Das heißt wenn Innerhalb eines kritischen Bereichs zwei mal gelockt wird, muss auch zwei mal unlock() aufgerufen werden ja?

Also:

```
public int fkt1()
{
      mutex.lock();     //Kritischer Bereich gesperrt, Counter = 1
      mutex.lock();     //Counter um 1 erhöht

...

      mutex.unlock(); //Counter um 1 verringert
      mutex.unlock(); //Counter = 0 => Kritischer Bereich wieder frei
}
```

Ein Thread der jetzt auf einen kritischen Bereich zugriefen möchte, muss quasi warten bis der Counter wieder = 0 ist?

Gruß
Happyman0815


----------



## SlaterB (26. Jul 2009)

sozusagen, ja,

wobei andere Threads Details wie Counter gar nicht interessieren müssen,
wenn man das ReentrantLock als Lock verwendet (Interface Lock), dann sind die Methoden zum HoldCount auch gar nicht sichtbar, falls sie überhaupt von fremden Threads eingesehen werden können


----------



## Happyman0815 (26. Jul 2009)

Ok dann habe ich es jetzt wohl verstanden 

In C++ habe ich es gerne damit Semaphoren realisiert.

Also (C++):


```
fkt()
{
      mutex.lock();     //Kritischer Bereich gesperrt


      mutex.lock();     //Warten bis kritischer Bereich frei ist (scheinbarer Deadlock)

      mutex.unlock();  //Nachdem im es weiter gehen kann natürlich direkt wieder freigeben
}


//In einem Anderen Thread:
thread()
{

//... irgendwas
mutex.unlock(); //Jetzt kann die Funktion oben weiterarbeiten 

}
```

Evtl. gibt es da auch schönere Sachen, aber so hab ichs immer realisiert  Da gibt es diese Counter nämlich nicht.

Danke für die Hilfe!

Gruß
Happyman0815


----------

