FastSwitch

[EWeiss]

Zitat von Namenloser:

Achso, dann verstehe ich das. Dann müsste es doch aber genügen, vor dem Aufruf der Finalize-Routine ein globales Flag auf False zu setzen und hinterher auf True. Und wenn die "Nächstes Plugin laden"-Methode aufgerufen wird, während das Flag False ist, dann bricht die Methode ab (oder wartet, bis das Flag wieder True ist). Natürlich noch threadsafe, das ganze. Läuft dann eigentlich auf ganz einfaches, normales Locking hinaus. Übersehe ich etwas?

Werde das mal testen
Normalerweise hab ich so was nicht gebraucht wenn die Anwendung die Lib Ordnungsgemäß behandelt.
Wie ein normal Mensch darauf kommen kann einfach den Button (taste) gedrückt zu halten ist mir unbegreiflich.

Danke.

EDIT:
Funktioniert leider nicht!
Wenn die so schnell umgeschaltet werden kommt mein Thread nicht mehr mit
Bei normalen gebrauch hingegen gibt es keine Probleme.


gruss

[Furtbichler]

Wieso verwendest Du nicht einfach einen separaten Thread zum Laden des nächsten Plugins. Dieser Thread meldet, wenn er fertig ist und ein weiteres Plugin laden kann. Während der Thread beschäftigt ist, kann man eben nicht scrollen. Das ersetzt deine statische Konstante.

Wenn ich eine Liste von Dingern habe, bei denen ich nur alle 2 Sekunden weiterklicken kann, ist das -mit Verlaub- unzumutbar. Das sind doch bloß irgendwelche DLL, was soll daran 2 Sekunden dauern?

[EWeiss]

Zitat von Furtbichler:

Wieso verwendest Du nicht einfach einen separaten Thread zum Laden des nächsten Plugins. Dieser Thread meldet, wenn er fertig ist und ein weiteres Plugin laden kann. Während der Thread beschäftigt ist, kann man eben nicht scrollen. Das ersetzt deine statische Konstante.

Wenn ich eine Liste von Dingern habe, bei denen ich nur alle 2 Sekunden weiterklicken kann, ist das -mit Verlaub- unzumutbar. Das sind doch bloß irgendwelche DLL, was soll daran 2 Sekunden dauern?

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.

Die meckern ja schon wenn die eine last von 20% CPU haben was soll das erst geben wenn man 2 gleichzeitig starten kann.

Mein Problem ist eigentlich ganz einfach zu erklären.
Der Thread ist nicht beendet wenn das neue Plugin startet.
bzw.. der nächste BeginThread aufgerufen wird.

Wie kann ich garantieren das dieser vorher 100% beendet wurde.

Zitat:

Das sind doch bloß irgendwelche DLL, was soll daran 2 Sekunden dauern?

Wenn man das so Pauschal sagen könnte ja, ist aber nicht der Fall

Ist es möglich das WaitForSingleObject Probleme macht?

Delphi-Quellcode:

    hEvent := CreateEvent(nil, True, False, nil);
    PostThreadMessage(RenderThreadId, WM_QUIT, 0, hEvent);
    WaitRe := WaitForSingleObject(hEvent, 1000);
    CloseHandle(hEvent);

im Thread signalisiere ich wenn er beendet wurde
  SetEvent(Msg.LParam);

Das trifft aber nicht rechtzeitig ein egal ob ich jetzt 1 oder 10 Sekunden übergebe


gruss

[Sir Rufo]

Du wirst wohl eine Kontrollinstanz einsetzen müssen, die das Laden/Entladen der Plugins regelt.

Das könnte ja auch ein Thread sein.

Der weiß, welches Plugin geladen ist und stößt das Entladen an, wenn ein anderes Plugin geladen werden soll.
Sobald das alte Plugin entladen ist, wird das gewünschte Plugin geladen.
Dieser Plugin-Wunsch, kann sich während dieser Zeit ändern, sooft wie möglich, erst wenn das alte Plugin weg ist, dann wird dieser aktuelle Wunsch geladen.

Die Kontrollinstanz hätte z.B. folgende Zustände ( NoPlugin, LoadPlugin, UnloadPlugin, ReadyPlugin ) Während der Zustände LoadPlugin und UnloadPlugin würde einfach nur der Plugin-Wunsch vermerkt ohne eine Reaktion auszulösen.

In den Zuständen NoPlugin und ReadyPlugin bzw. beim Erreichen dieser Zustände, wird der aktuelle Wunsch mit dem aktuellen Plugin verglichen und im Bedarfsfall reagiert.

[Furtbichler]

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.

Zitat von EWeiss:

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.

[EWeiss]

Zitat:

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.

Keine sorge fühle mich nicht auf den Schlips getreten.

Zitat:

vielleicht noch fehlender Programmierkenntnisse

JO.. Wenn ich Profi wäre müsste ich nicht fragen

Jeder wird irgendwann an seine grenzen stoßen.. aber wie gesagt kein Problem für mich da jetzt drauf rumzureiten.

Ich such nach einer Lösung die mit meinen Kenntnissen nicht so einfach umzusetzen ist.
So kann ich es auf Dauer jedoch nicht belassen.

Zitat:

Der Ansatz von Sir Rufo ist doch brauchbar.

Ist mir noch nicht ganz klar wie ich das umsetzen soll..
Kleines Beispiel ? Von mir aus auch mit Thread

Nebenbei mein Thread wird mit BeginThread erstellt (API)


gruss

[Furtbichler]

Emil. Schöne Antwort.
Mal ganz grob dahingerotzt. Der TPluginLoader ist ein Thread, der wartet, bis er ein Plugin (neu) laden soll. Das wird ihm mit einer Semaphore mitgeteilt (Du kannst auch ein Event nehmen). Derjenige, der jetzt ein neues Plugin will, ruft einfach 'LoadPlugin' auf. Über das Event 'OnSignalPluginLoaded' wird ihm dann mitgeteilt, wenn das Plugin geladen wurde. Der Aufrufer kann jetzt also andere Dinge erledigen, wie z.B. Maus/Tastendrücke verarbeiten oder Kaffeetrinken.

Delphi-Quellcode:

Procedure TPluginLoader.Execute;
Begin
  While not terminated do
    if WaitForSingleObject(fSyncHandle, INFINITE) = WAIT_OBJECT0 then begin
      thisPlugin := NextPlugin;
      UnloadPlugin(CurrentPlugin);
      LoadPlugin(thisPlugin);
      Synchronize(SignalPluginLoaded);
    end 
    else Terminate := True; // Handle wurde wohl geschlossen
End;

Procedure SignalPluginLoaded;
Begin
  if Assigned (OnSignalPluginLoaded) then 
    SignalPluginLoaded(self, CurrentPlugin);
End;

Procedure TPluginLoader.LoadPlugin(aPlugin : TPlugin);
Begin
  NextPlugin := aPlugin;
  ReleaseSemaphore(fSyncHandle,1,nil);
End;

Auf die Typdeklaration des Threads sowie weitere Schutzmechanismen zum Setzen/Abfragen des aktuellen/nächsten Plugins mit critical sections habe ich mich jetzt nicht gekümmert. Auch fehlt der code, der 'CurrentPlugin' setzt oder die von Rufo vorgeschlagene Statusänderung (die ich über Events publizieren würde).

Wenn Du damit (noch) nicht klarkommst, dann wird dir hier bestimmt weitergeholfen. Wichtig ist hier das Prinzip der Signalisierung/Synchronisierung nebenläufiger Prozesse über Synchronisationsobjekte (Mutexe, Events, Semaphoren) und Events (OnXXXX).

[EWeiss]

Zitat:

Wenn Du damit (noch) nicht klarkommst, dann wird dir hier bestimmt weitergeholfen. Wichtig ist hier das Prinzip der Signalisierung/Synchronisierung nebenläufiger Prozesse über Synchronisationsobjekte (Mutexe, Events, Semaphoren) und Events (OnXXXX).

Und das ist womit ich mich noch nicht beschäftigt habe
na ja ich kann jetzt nicht neue API's einbauen, denke aber das ich den Thread dann nur innerhalb meiner Function verketten muss.

Delphi-Quellcode:

procedure BASSVIS_ExecutePlugin(Param: PBASSVIS_EXEC; var Base: TBASSVIS_PARAM);
  stdcall;

wenn eine neue Anfrage kommt und der alte Thread noch nicht beendet wurde.
Danke für die Infos..


gruss

[EWeiss]

komme da nicht mit klar muss da wohl passen..
Aber trotzdem nochmal Danke für die Hilfe.

gruss

[BUG]

Zitat von EWeiss:

Wie ein normal Mensch darauf kommen kann einfach den Button (taste) gedrückt zu halten ist mir unbegreiflich.

Das deutet darauf hin, das dass Navigieren durch die PlugIns umständlich ist. Ich würde das auch versuchen.

Um nochmal Furtbichlers ersten Vorschlag anzusprechen: Du solltest auf keinen die Benutzerschnittstelle verlangsamen; damit wirkt einfach dein Programm fehlerhaft.
Eher solltest du den Nutzer so schnell umschalten lassen, wie er möchte, und dann etwas verzögert das PlugIn nachladen (also wenn er sich "entschieden" hat).