Threadverarbeitung und Mutex

[Bisonte]

Hallo.

Ich stöber im Forum schon eine ganze Weile, aber finde nichts zu folgender Frage :

Sind mehrere Mutex (Mehrzahl ?) möglich, bzw. sinnvoll ?

Ich habe verschiedene Listen, die ich gern einzelnd absichern würde, da sie in verschiedenen
Threads benutzt werden (bzw. deren Elemente per Pointer)

Macht man das mit mehreren Mutex... oder nur mit einem ? Weil alle Codes die ich bisher gesehen
habe, beinhalten immer nur einen Mutex... allerdings war auch kein Code bisher so gross (hier im
Forum) das er mehrere bräuchte in meinen Augen.

[RSBasic]

Es kommt drauf an, ob du bei zwei Listen unterschiedlich auf Benutzung warten möchtest oder ob die zwei Listen zusammenhängen.
D.h. wenn beide Listen unabhängig bearbeitet werden, die miteinander nichts zu tun hast, dann kannst du 2x Mutex erstellen.
Aber getestet habe ich in meinen Projekten bisher immer nur mit einem Mutex und mit einem Semaphore.

[Kiffi]

mehrere Mutex (Mehrzahl ?)

Mutti!

https://de.wiktionary.org/wiki/Mutex

[Bisonte]

Ah ok. Also mehrere Mutexe sind möglich. Danke.

[HeX0R]

In meinem aktuellen Projekt habe ich 3 Mutex + 3 Semaphoren.
Es kommt immer drauf an, wo man was schützen möchte, und ob es Sinn macht das mit lediglich einem Mutex zu tun.

Ich habe das vor allem deswegen gemacht, weil es Blödsinn wäre, einen Programmteil unnötig anzuhalten, wenn er auf was ganz anderes wartet.

[NicTheQuick]

Mehrere Mutexe müssen aber auch wohl überlegt eingesetzt werden, damit es zu keinen Deadlocks kommt. Für einen Deadlock reichen schon zwei Mutexe, die von zwei Threads in verschiedenen Reihenfolgen gesperrt werden. Beispiel (oder Wikipedia):

Code: Alles auswählen

Global mutex1.i = CreateMutex()
Global mutex2.i = CreateMutex()

Procedure thread1(dummy.i)
	Repeat
		LockMutex(mutex1)
		LockMutex(mutex2)
		
		Debug "Thread 1"
		
		UnlockMutex(mutex2)
		UnlockMutex(mutex1)
	ForEver
EndProcedure

Procedure thread2(dummy.i)
	Repeat
		LockMutex(mutex2)
		LockMutex(mutex1)
		
		Debug "Thread 2"
		
		UnlockMutex(mutex1)
		UnlockMutex(mutex2)
	ForEver
EndProcedure

CreateThread(@thread1(), 0)
CreateThread(@thread2(), 0)

Delay(10000)

Es muss außerdem darauf geachtet werden, dass Mutexe immer in der umgekehrten Reihenfolge wieder entsperrt werden wie sie gesperrt wurden.
Was man auch wissen muss: Ein einzelner Thread kann einen Mutex mehr als nur einmal sperren (Reentrantlock). Um ihn wieder entsperren zu können, muss er genau so oft entsperrt werden wie er auch gesperrt wurde. Warum ist das sinnvoll? Man muss sich so um weniger kümmern. Beispiel: Ich habe mehrere Procedures, die auf den selben Daten arbeiten und dafür am Anfang der Procedure den Mutex sperren und am Ende wieder entsperren. Wenn man jetzt innerhalb einer Procedure eine andere Procedure aufruft, die ebenfalls den Mutex sperrt, dann kommt es nicht zum Stillstand des Programms. Hier ein Code, der es ganz einfach demonstriert:

Code: Alles auswählen

Global mutex.i = CreateMutex()

Procedure tuwas()
	LockMutex(mutex)
	Debug "tuwas()"
	UnlockMutex(mutex)
EndProcedure

Procedure machmal()
	LockMutex(mutex)
	Debug "machmal() Start"
	tuwas()
	Debug "machmal() Ende"
	UnlockMutex(mutex)
EndProcedure

machmal()

Im Forum sollte es außerdem ein paar Codes geben, die mehrere Mutexe nutzen. Meine OOP-Include erstellt zum Beispiel für jedes Objekt einen eigenen Mutex, damit man Methoden synchron ausführen kann.

[#NULL]

Wie bereits gesagt, wenn man die Reihenfolge nicht beachtet, dann ist der Plural von Mutex Deadlock

[Nino]

Wie bereits gesagt, wenn man die Reihenfolge nicht beachtet, dann ist der Plural von Mutex Deadlock

Jetzt habe ich diese Thematik endlich mal verstanden.

[mk-soft]

Ich weiss nicht ob das bei Purebasic immer noch so ist!

Ich glaube PB verwendet intern bei Windows nicht Mutex, sondern CriticalSection...

[RSBasic]

Ich glaube PB verwendet intern bei Windows nicht Mutex, sondern CriticalSection...

Ja, die API-Aufrufe, die ich bei einer Test-Executable-Datei ermitteln konnte: EnterCriticalSection_(), LeaveCriticalSection_(), TryEnterCriticalSection_(), InitializeCriticalSection_(), DeleteCriticalSection_()