@Sir Rufo: dann habe ich aber das Problem, dass ich das EventListener-Konzept nicht mehr halten kann, welches ich aber sehr verständlich finde, eben auch sehr lesbar für andere Programmierer. Aber gut ich werde mir mal Gedanken über diese Nachrichten-System machen. Eine Basis-Klasse oder ein Interface als "Log-Listener", die die Messages annimmt und weiterleitet bzw. entsprechend verarbeitet würde es ja schon tun. Aber ich wollte ganz gerne komplett unabhängig sein.
Eine Idee, die auf Messages basieren würde, wäre es, einen internen Thread im LogController laufen zu lassen, der auf neue Einträge in einer internen Queue reagiert und somit parallel zu allen anderen läuft. Ist ein Log in der Queue vorhanden, so wird diese (synchronisiert) weiterleitet -> EventListener-Konzept bleibt bestehen. Der LogController, bei dem neue Logs gemeldet werden, schickt diesem internen Thread Messages mit den entsprechenden Log-Meldungen. Dieser interne Thread gibt diese Meldungen dann auch frei. Somit wird das Freigeben nicht an den Benutzer verlagert und ich brauche keine Basis-Klasse bzw. ein Interface.
Allerdings habe ich gedanklich folgendes Problem: Thread A schreibt einen Log und betritt somit die CriticalSection. Der MainThread kommt nun und will auch eine Log-Meldung absetzen, wobei dieser nun warten muss, da Thread A ja gerade in die Log-Queue schreibt. Genau in diesem Moment kommt nun der interne Thread des LogControllers und will synchronisiert eine Meldung schreiben, aber der MainThread ist ja gerade im wartenden Zustand... Kann das zu einem Deadlock führen?!
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)