Hi,
all die Probleme die Du nennst sind im Prinzip immer möglich. Um sie zu vermeiden muss eben synchronisiert bzw. gesperrt werden. Das Lesen bzw. Schreiben eines primitiven Typen wird i.d.R. als atomar angesehen (stellt sich immer die Frage was primitiv hier bedeutet), der ganze Rest kann immer Überschneidungen mit sich bringen.
Wenn Du auf eine fremde Komponente zugreifst, so ist es einfach wichtig zu wissen, ob diese Threadsafe ist oder nicht. Ist dies nicht der Fall, musst Du Dich selbst um die Synchronisation kümmern, mit allen Freiheiten und Gefahren. Dabei basiert gute Synchronisation immer auf dem Prinzip so spät wie möglich, so lang wie nötig (also bei Sperrsynchronisation). Man sperrt den Zugriff auf Ressourcen also immer erst, wenn es wirklich nötig wird und gibt die Sperren möglichst schnell wieder frei, hält sie aber auch wirklich bis sicher ist, dass es nicht zu einer Verklemmung kommen kann.
Zitat von
jensw_2000:
Da ich nur einen Thread - den Haupt-Thread der Applikation - habe und die Eventhandler durch die
API des Herstellers synchronisiert aufgerufen werden, gehe ich davon aus, das immer ein Event zur Zeit ausgelöst wird, dass anschließend die Ereignisbehandlingsroutine aufgerufen und incl. aller darin aufgerufenen Subroutinen abgearbeitet wird. Anschleißend feuert das nächste, ggf. anstehende, Event der
API. Somit sind also keine Parallelitätsprobleme zu erwarten.
Genaus das stimmt so nicht bzw. muss so nicht stimmen. Das Event-Handling kann sehr gut von der Benachrichtigung über das Eintreffen eines Ereignisses entkoppelt werden. Hier kann die
API z.B. auf einen Dispatcher zugreifen, der das Event-Handling auf Worker-Threads verteilt. Sind diese threadsafe, so wird dabei keineswegs verlangt, dass die nicht parallel arbeiten, es muss eben nur sichergestellt werden, dass das Result der seriellen Abarbeitung entspricht. Wie das erreicht wird ist egal (da gibt es Möglichkeiten wie Sperrsynchronisation, Zeitstempel-Verfahren oder auch optimistische Verfahren die einfach keinen Konflikt annehmen und ggf. eben eine Aktion rückgängig machen). Das beste Verfahren kann man nicht benennen, kommt immer darauf an, was für Zugriffe erfolgen.
Jedenfalls musst Du hier wirklich schauen, was genau die Komponente für Dich bereits übernimmt. Alles was Du selbst implementierst ist erstmal nicht threadsafe (außer die Komponente sichert das irgendwo zu oder Du sorgst selbst dafür). Davon auszugehen, dass die Komponente immer ein Event komplett abarbeitet bevor das nächste bearbeitet wird solltest Du auf keinen Fall. Selbst wenn das auf verschiedenen Systemen 999.999 mal der Fall ist, beim nächsten mal muss das nicht der Fall sein. Hier kann man sich nie auf Beobachtung verlassen, man muss es sicherstellen (z.B. durch eine Zusicherung der Doku oder eben durch ein eigenes Verfahren).
Wie gesagt, möglich/denkbar sind viele Probleme, kommt drauf an was die Komponente schon leistet (oder eben nicht). Selbst synchronisieren solltest Du nur wenn Du musst (kostet Perfomance und ist fehleranfällig). Ist die schon synchronisiert, solltest Du auf keinen Fall noch zusätzliche Sperren einführen (der Overhead ist schnell größer als jeglicher Gewinn durch die parallele Abarbeitung).
Gruß Der Unwissende