Der eine wartet mit 'WaitForSingleObject', der andere signalisiert (SetEvent, ReleaseSemaphore etc.), das der eine das Warten beenden kann.
Damit der Wartende zwischendurch andere Sachen machen kann, erlaubt der Aufruf von 'WaitForSingleObject' die Angabe einer maximalen Wartezeit. Der Rückgabewert ('WAIT_TIMEOUT'/ WAIT_OBJECT0') signalisiert, ob während des Wartens das Signal vom anderen gekommen ist, oder nicht, Ein Wert von -1 ('INFINITE') als maximale Wartezeit wartet eben so lange, bis das
Handle geschlossen wurde ('CloseHandle') oder das Signal erfolgte.
Aber es ist auch klar, das hier zwei Threads am werkeln sein müssen: Einer, der wartet und einer, der signalisiert.
Genau das möchte ich verhindern.. Die Anwendung soll nicht Multithread fähig sein.
Also es soll und darf nicht mehr als ein Plugin zur gleichen zeit geladen werden.
Das hat mit Multithreading nichts zu tun. In einem Thread können blockierende/synchronisierte Aufrufe durchgeführt werden, ohne die Hauptanwendung zu blockieren. Ich will doch kein tolles schickes Sound-Tool haben, das zwischendurch weder auf Maus- noch auf Tastendrücke reagiert. Also: Laden des Plugins in einen Thread auslagern. Solange davon nur einer läuft, ist deine Forderung erfüllt, oder? Der Ansatz von Sir Rufo ist doch brauchbar.
Zitat:
...eine last von 20% CPU haben
Soweit ich mich erinnere, sind andere Implementierungen hier wesentlich weniger rechenintensiv. Ich glaube (bzw. behaupte in Unkenntnis der Details), Du machst hier etwas Grundlegendes falsch. Ich will Dir nicht zu nahe treten, aber bei der Frage nach der Parametrierung der Synchronisationsgeschichten ('WaitForSingleObject') und auch bei den selbsterdachten Hindernissen ('nicht Multithread fähig sein') scheint es mir, das Du das Optimierungspotential deiner Anwendung aufgrund vielleicht noch fehlender Programmierkenntnisse noch nicht ausgeschöpft hast.