TThread mit WaitForMultipleObjects in DLL arbeitet nicht ?

[Bernd Ua]

Zitat:

Ich habe nur im TimerThread Synchronize weggelassen und schon gings

So war das nicht gemeint, mit nicht verwenden!!!!!

Dein Eventhandler im Hauptprogramm läuft dann im aufrufenden Thread und das
wirst Du früher oder später bereuen ! Lass es sein !

das Chaos ist dann nicht mehr zu managen - weil Du nach kurzer Zeit nicht mehr weisst,
was in welchem Threadkontext läuft. Und Zugriff auf VCL-Klassen aus mehreren Threads wird
knallen !
Dasselbe gilt im übrigen für Deine published properties
( mal abgesehen davon, dass published bei Klassen die nicht
TPersistent abstammen oder {$M+} verwenden eh unsinnig ist).

Ein Zugriff die Properties deiner Klasse während der Thread läuft,
ist nur auf einer Ein-Prozessor-Maschine relativ gefahrlos möglich.
Auf einem Mehrprozessorsystem ( oder auch einer neuen Intel CPU mit aktiviertem
Hyperthreading !!) sind Intergeroperationen nicht atomar!
Verwende mindestens die InterLockedxxxx Funktionen des OS für die
Eigenschaftsimplementierung oder kapsele die Datenfelder des Threads.

Bernd

[Rumpi]

Hallo Bernd

Zitat von Bernd Ua:

So war das nicht gemeint, mit nicht verwenden!!!!![/b]

Dein Eventhandler im Hauptprogramm läuft dann im aufrufenden Thread und das
wirst Du früher oder später bereuen ! Lass es sein !
Bernd

Danke für den Hinweis, da brennt bei mir jedoch schon seit Jahren nix mehr an!
- CriticalSection
- Mutex
- ThreadList

Das UI ist in meinen Anwendungen "mittlerweile" austauschbar.

Genau das mache ich zum Beispiel in der DLL, die muss sich
um die Hardware und die interne Verwaltung (Optionen) kümmern.
Mein Kollege hängt sich da mit dem CBuilder 6 ein.

Mein UI kann sogar parallel eingreifen es geht sogar soweit,
dass man sich mit einem UI auf einem anderen
PC im Netzt via IP einloggen kann und die Oberfläche
synchronisiert sich.

Die Leute in unserer Fa. haben echt Bauklötze gestaunt
als sich unsere Hardware das erste mal
zum Einen Lokal und zum Anderen im Netz parallel steuern ließ!


mfg Rumpi

[Rumpi]

Delphi-Quellcode:

destructor TTimerThread.Destroy; 
begin 
  FCloseEvent.Free; 
  FEnableEvent.Free; // ups hatte ich vergessen
  Inherited Destroy; 
end;

mfg Rumpi

[negaH]

Also, ich verstehe auch nicht was sich technisch mit deinem TimerThread gegenüber einem TTimer verbessern sollte. Durch das Synchronize() machst du die Vorteile eines Threads gegenüber einem TTimer kaputt, und verschlimmbesserst sogar noch die Gesamtstabilität der Anwendung. Ausserdem sind Threads nicht resourcenschonender als Timer. Ein Timer benötigt zwar ein Window Handle, dafür benötigen Threads während ihrer aktiven Phase und dem Contextswitch mehr Resourcen. Betrachten auf die Zeitresolution sind Threads auch nicht besser als Timer. Beide können nur runter bis auf 1 ms, und sind unterhalb 50 ms nicht mehr exakt.

Nur falls der Thread ohne Synchronize() auskäme würde man einen Vorteil erlangen.

Gruß Hagen

[Rumpi]

Hi Hagen,

vielen Dank für deinen Hinweis,
genau das "Synchronize" war ja auch das Deadlock Problem in der DLL.
Du siehst am Code das ich
//Notify; schon stehen hatte.
Ich werde noch FSyncMode dazu fügen.

Der Vorteil für mich ist "nicht nur", dass ich den TTimerThread nur mit
einer Zeile erzeuge
 FTimerThread := TTimerThread.Create( Interval, Notify ); und auch nur mit einer wieder
  FTimerThread.Stop; freigebe.

Desweiteren verwende ich ihn auch um ein/mehrer (MuliMonitor) UI's jede Sekunde (+- 50ms)
  FTimerThread := TTimerThread.Create( Notify ); zu updaten ( siehe FOneSec ).

In einem Programm laufen davon mehr als 10
- Unabhängige Hardware Connects ( Seriell )
- Unabhängige Hardware State Checks
- Unabhängige IP Re/Connects Client seitig
- ...

ca. 10-20 Threads, noch nicht einmal die Hardware
Threads der Seriellen oder SaredMemory Kommunikation
dazu gerechnet. Es ist wirklich ein ganzer
"Batzen an TTimer nötig" ... und die kann man nun mal
nur Begrenzt verwenden, oder?

Jeder kann für sich entscheiden ob er
einen Thread anstelle eines TTimers verwendet.

Klar ist wohl auch jedem, dass ich in der
Anwendung alles Threadsicher halten muss.
Mit diesem Gedanken gehe ich seit D2 immer
an ein Projekt, es ist für mich einfacher
sofort CriticalSection's ( ob nun Global oder Local),
Mutex und ThreadList's zu arbeiten.
Schon wegen der nicht Synchron arbeitenden Hardware ( siehe oben )
und den multiplen Steuerungsmöglichkeiten.
z.B.
- Mehrfach Local als MultiMonitor
( mit eigenem TouchScreen Funktionen ohne System Treiber,
so das du eine Maske auf Screen 2 bedienen kannst und
parallel auf Screen 1 mit der Maus fuchtel kannst um
eine andere Maske zu bedienen )
- Mehrfach Dezentral im Netz

... und es Funktioniert!

Was immer noch offen ist:

Warum der Deadlock in einer DLL wenn ich
Synchronize( FNotify ); verwende?

Vielen Dank noch einmal Hagen.
Für jeden Input dankbar! (No.5 lebt )

mfg Rumpi No.5

[negaH]

Wenn soviele Timer nötig sind, dann ist es besser nur einen einzigsten "Multi-Timer-Thread" zu programmieren. Man nimmt also einen einzigsten Thread der aber eine Liste von Intervallen verwaltet. Nun berechnet er ausgehend von diesen Intervallen die Dauer in Millisekunden bis zum nächsten Ereigniss. Angenommen drei Intervalle 100ms und 500ms. Der Thread wartet immer 100ms und lösst das 100ms Ereignis aus, alle 5 mal das 500ms Ereignis. Einen solchen Timer-Thread habe ich selber schon gecodet.
Vorteil dabei ist das alle Ereignisse zueinander "synchrone" sind, d.h. sie überschneiden sich nicht in deren Ausführung.

Gruß Hagen

[negaH]

Wenn soviele Timer nötig sind, dann ist es besser nur einen einzigsten "Multi-Timer-Thread" zu programmieren. Man nimmt also einen einzigsten Thread der aber eine Liste von Intervallen verwaltet. Nun berechnet er ausgehend von diesen Intervallen die Dauer in Millisekunden bis zum nächsten Ereigniss. Angenommen drei Intervalle 100ms und 500ms. Der Thread wartet immer 100ms und lösst das 100ms Ereignis aus, alle 5 mal das 500ms Ereignis. Einen solchen Timer-Thread habe ich selber schon gecodet.
Vorteil dabei ist das alle Ereignisse zueinander "synchrone" sind, d.h. sie überschneiden sich nicht in deren Ausführung.

Gruß Hagen

[Rumpi]

Hi Hagen,

danke für den Tip, ich werde eine NotifyChain in die classe aufnehmen.
Geht bei meinen Anwendungen aber leider nicht.


mfg Rumpi

[the_Sisyphos]

noch eine kleine Anmerkung nebenbei zu WaitForMultipleObjects über die ich beim Programmieren eines IP Scanners gestolpert bin .. diese Funktion kann nur mit maximal MAXIMUM_WAIT_OBJECTS Threads umgehen und dies sind (zumindest unter Delphi 6) 64 Stück. Wobei man zudem bedenken sollte das scheinbar diese Zahl die Gesamtzahl an Threads ist die Delphi ohne Probleme verwalten kann. Nachdem das Hauptprogramm auch in einem eigene läuft reduziert sich somit die maximal verfügbare Anzahl mit jedem weiteren Thread der sonst noch neben dem Hauptprogram läuft.

Das heißt NICHT das Delphi nicht mehr TThreads aufmachen kann, aber das heißt das die Funktion WaitForMultipleObjects ab sofort nurnoch -1 zurück liefert, also weder WAIT_OBJECT_0, WAIT_TIMEOUT noch WAIT_FAILED zurückliefert!!! Das heißt aber auch das bei einem normalen Programmfluß in dem das nicht abgefangen wird, das Programm schlicht weiter läuft anstatt stehen zu bleiben was unschöne Effekte haben kann.