![]() |
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 |
AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
Zitat:
Mehr zu diesem Thema habe ich auf meine Anfrage bei Stackoverflow erfahren: "Is it dangerous to use synchronize in a non-VCL application?" ![]() |
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. |
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 |
AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
Zitat:
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 :-) |
AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
![]() Steht aber eigentlich schon in dem verlinkten stackoverflow-Artikel oben. |
AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
Zitat:
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 ;-) |
AW: MultiThreading Ereignisbearbeitung GUI Applikation / Service
Zitat:
Ansonten würden ich auch eher Critical Sections empfehlen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:04 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz