Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   MultiThreading Ereignisbearbeitung GUI Applikation / Service (https://www.delphipraxis.net/176558-multithreading-ereignisbearbeitung-gui-applikation-service.html)

Niotronic 13. Sep 2013 10:03

MultiThreading Ereignisbearbeitung GUI Applikation / Service
 
Hallo,
meine Applikation kann sowohl als GUI Applikation als auch als Service gestartet werden und kommuniziert über einen oder mehrere Comports also auch mit dem Firebird Server über IBObjects. Als Applikation läuft alles wunderbar. Wird das ganze als Service gestartet läuft es zwar prinzipiell auch, jedoch crasht es meist nach wenigen Minuten. Als Ursache habe ich die offenbar parallele Abarbeitung von Ereignissen des Comports (OnRxChar, OnTimeOut, On SendData) erkannt, d.h. bei Betrieb als Applikation werden diese Ereignisse wie zu erwarten (werden von der TComport Komponente (von WinSoft.sk) da mit Synchronize aus dem Comport Thread aufgerufen streng sequentiell abgearbeitet. Bei Betrieb als Service werden diese Ereignisse teilweise gleichzeitig abgearbeitet - d.h. während gerade Daten empfangen werden wird das timer gesteuerte Ereignis SendData abgearbeitet - die Events scheinen sich gegenseitig zu unterbrechen (Interrupt like), was darauf hindeutet, das die Synchronizeaufrufe nicht mehr mit dem hauptthread synchronisiert werden ?
Warum unterscheidet sich die Ereignisbearbeitung bei Betrieb als Applikation und als Service ?

mfg

Klaus

mjustin 13. Sep 2013 10:38

AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
 
Zitat:

Zitat von Niotronic (Beitrag 1228316)
was darauf hindeutet, das die Synchronizeaufrufe nicht mehr mit dem hauptthread synchronisiert werden ?

Synchronize synchronisiert mit dem VCL Hauptthread. Es ist gefährlich in einer nicht-VCL Anwendung synchronize zu verwenden. Ich würde daher den Hersteller (Winsoft) kontaktieren.

Mehr zu diesem Thema habe ich auf meine Anfrage bei Stackoverflow erfahren:

"Is it dangerous to use synchronize in a non-VCL application?"

http://stackoverflow.com/questions/1...cl-application

taveuni 13. Sep 2013 12:13

AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
 
Scheint mir ein Designproblem zu sein. Wir haben auch diverse Entwicklungen welche sowohl als auch laufen.
Der Controller und alles darunter ist logischerweise identisch. Und nur im Falle eines GUI's - also beim
Start als Applikation wird Synchronize verwendet. Nämlich um die (VCL-) Anzeige zu aktualisieren.

Niotronic 13. Sep 2013 12:42

AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
 
Beim Zugriff auf VCL Komponenten kann man das leicht so machen - damit gibt es auch kein Problem - das Synchronize wird aber auch beim Aufruf von OnRxChar, OnRxTimeOut einer zugekauften Comport-Komponente verwendet - Mal sehen was winsoft.sk - der Hersteller der Comport Komponente dazu zu sagen hat...

mfg

Klaus

mjustin 13. Sep 2013 12:46

AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
 
Zitat:

Zitat von taveuni (Beitrag 1228343)
Scheint mir ein Designproblem zu sein. Wir haben auch diverse Entwicklungen welche sowohl als auch laufen.

Verwenden diese auch Threads?

Da ein Thread nicht wissen kann, ob er in einem Service, einem Konsoleprogramm, unter OSX, Linux (Android) oder innerhalb einer VCL GUI Anwendung läuft, muss er entweder auf synchronize verzichten oder von der Anwendung 'informiert' werden, ob synchronize verwendet werden soll...

Und wie der rote Kasten mir gerade anzeigt, wird in Comport auch fleißig Synchronize verwendet :-)

Olli73 13. Sep 2013 13:26

AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
 
http://docwiki.embarcadero.com/Libra...eckSynchronize

Steht aber eigentlich schon in dem verlinkten stackoverflow-Artikel oben.

mjustin 13. Sep 2013 13:40

AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
 
Zitat:

Zitat von Olli73 (Beitrag 1228357)
http://docwiki.embarcadero.com/Libra...eckSynchronize

Steht aber eigentlich schon in dem verlinkten stackoverflow-Artikel oben.

CheckSynchronize ist nur notwendig, wenn man den Code, der synchronize aufruft (in einer nicht-VCL Anwendung) nicht unter eigener Kontrolle hat. (Zum Beispiel wenn man nur DCUs und nicht den Sourcecode hat.

Wenn der Thread "weiss", dass er kein synchronize braucht, ist auch CheckSynchronize nicht notwendig, sondern nur Overhead (bzw. eine Lösung für ein Problem, dass man ohne synchronize nicht hat).

synchronize ist so etwas wie das GOTO (oder with) der Delphi Threadprogrammierung. IMHO. Ok, ich verwende es in eigenem Code - aber mit einem 'if ...' davor ;-)

Olli73 13. Sep 2013 13:47

AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
 
Zitat:

Zitat von mjustin (Beitrag 1228360)
CheckSynchronize ist nur notwendig, wenn man den Code, der synchronize aufruft (in einer nicht-VCL Anwendung) nicht unter eigener Kontrolle hat.

Also wie im konkreten Fall gegeben. Er benutzt Komponenten, die synchronize benutzen und kann (oder will?) die nicht anpassen. ;)

Ansonten würden ich auch eher Critical Sections empfehlen.


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:54 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz