Threadverarbeitung und Mutex
Threadverarbeitung und Mutex
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.
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.
PureBasic 6.10 LTS (Windows x86/x64) | Windows10 Pro x64 | Asus TUF X570 Gaming Plus | R9 5900X | 64GB RAM | GeForce RTX 3080 TI iChill X4 | HAF XF Evo | build by vannicom
Re: Threadverarbeitung und Mutex
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.
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.
Re: Threadverarbeitung und Mutex
Ah ok. Also mehrere Mutexe sind möglich. Danke.
PureBasic 6.10 LTS (Windows x86/x64) | Windows10 Pro x64 | Asus TUF X570 Gaming Plus | R9 5900X | 64GB RAM | GeForce RTX 3080 TI iChill X4 | HAF XF Evo | build by vannicom
- HeX0R
- Beiträge: 2962
- Registriert: 10.09.2004 09:59
- Computerausstattung: AMD Ryzen 7 5800X
96Gig Ram
NVIDIA GEFORCE RTX 3060TI/8Gig
Win10 64Bit
G19 Tastatur
2x 24" + 1x27" Monitore
Glorious O Wireless Maus
PB 3.x-PB 6.x
Oculus Quest 2 - Kontaktdaten:
Re: Threadverarbeitung und Mutex
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.
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.
{Home}.:|:.{Codes}.:|:.{Downloads}.:|:.{History Viewer Online}
- NicTheQuick
- Ein Admin
- Beiträge: 8679
- Registriert: 29.08.2004 20:20
- Computerausstattung: Ryzen 7 5800X, 32 GB DDR4-3200
Ubuntu 22.04.3 LTS
GeForce RTX 3080 Ti - Wohnort: Saarbrücken
- Kontaktdaten:
Re: Threadverarbeitung und Mutex
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):
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:
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.
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)
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()
Re: Threadverarbeitung und Mutex
Wie bereits gesagt, wenn man die Reihenfolge nicht beachtet, dann ist der Plural von Mutex Deadlock
Re: Threadverarbeitung und Mutex
Jetzt habe ich diese Thematik endlich mal verstanden.#NULL hat geschrieben:Wie bereits gesagt, wenn man die Reihenfolge nicht beachtet, dann ist der Plural von Mutex Deadlock
Re: Threadverarbeitung und Mutex
Ich weiss nicht ob das bei Purebasic immer noch so ist!
Ich glaube PB verwendet intern bei Windows nicht Mutex, sondern CriticalSection...
Ich glaube PB verwendet intern bei Windows nicht Mutex, sondern CriticalSection...
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Re: Threadverarbeitung und Mutex
Ja, die API-Aufrufe, die ich bei einer Test-Executable-Datei ermitteln konnte: EnterCriticalSection_(), LeaveCriticalSection_(), TryEnterCriticalSection_(), InitializeCriticalSection_(), DeleteCriticalSection_()mk-soft hat geschrieben:Ich glaube PB verwendet intern bei Windows nicht Mutex, sondern CriticalSection...