Autor Beitrag
pepper85
Hält's aus hier
Beiträge: 4



BeitragVerfasst: Di 29.09.09 23:34 
Hi,

mein Problem ist folgendes.
Ich habe ein Event was ausgelöst wird wenn eine berechnung fertig ist. Die Berechnung ist abhängig von einem anderen Programm was ich per Schnittstelle anspreche.
Normalerweise kann man mit Lock unterbinden, dass zwei Events parallel auf den gleichen Codeabschnitt zugreifen aber ich habe in der MSDN einen kleinen Eintrag gefunden, wo drin steht das wenn zwei Event nache gleichzeitig(stand leider keine genau ms Angabe drin) ausgelöst werden sie beide durch das Lock gehen können und dann einfach ein Befehl ignoriert wird.


Nun ist wie die Frage wie ich das Abfangen kann?
Hatte gedacht ich gebe einfach bei den Event einen Wert zurück aber dann ist da wieder ein Problem. Wenn die eine Anweisung einfach ignoriert wird wie krieg ich dann raus wann ich wieder aus dem Event rausspringe?
Thread.sleep bringt ja nicht da Event ja sprungziele sind und keine Threads oder?

Kann mir da jmd helfen?

Danke schonmal im vorraus
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Di 29.09.09 23:44 
:welcome: !

user profile iconpepper85 hat folgendes geschrieben Zum zitierten Posting springen:
aber ich habe in der MSDN einen kleinen Eintrag gefunden, wo drin steht das wenn zwei Event nache gleichzeitig(stand leider keine genau ms Angabe drin) ausgelöst werden sie beide durch das Lock gehen können
Wo hast du das denn her :shock: ? Monitor.Enter hat keine Schwachstelle, sonst wäre es ja vollkommen unnütz.

user profile iconpepper85 hat folgendes geschrieben Zum zitierten Posting springen:
[...]da Event ja sprungziele sind und keine Threads oder?
lock hat nichts mit Events zu tun, es geht rein um Threads. Bzw. kann es ohne mehrere Threads auch nicht passieren, dass ein Eventhandler mehrmals gleichzeitig betreten wird.

_________________
>λ=
pepper85 Threadstarter
Hält's aus hier
Beiträge: 4



BeitragVerfasst: Mi 30.09.09 00:00 
Hi danke für das willkommen.
also das mit dem events ist so.
ich spring beim ersten mal in die methode per event und rufe dort dann einen Backgroundworker auf.
dieser startet die Applikation wieder inclusive dem event. danach wird halt wieder gewartet,dass die berechung zu ende ist.
in der zeit kann es passieren, dass ein anderer thread das event auslöst. dort wird dann wieder ein Backgroundworker gestartet.
hm glaub ich schicke dir mal ein bissl code :)

mache ich, weil ich eine Server_Client applikation mit drin habe. Der Backgroundloader regelt dann die Kommunikation.
pepper85 Threadstarter
Hält's aus hier
Beiträge: 4



BeitragVerfasst: Mi 30.09.09 00:08 
hm da fällt mir grad ein.
der Backgroundworker hat ja zwei MEthoden aufrufe. einmal was er macht beim arbeiten und einmal die Methode wenn er fertig ist.
in der Methode wenn er fertig ist, ist er doch wieder im Hauptthread oder?
weil dort erstelle dích dann wieder das Event.
danielf
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 1012
Erhaltene Danke: 24

Windows XP
C#, Visual Studio
BeitragVerfasst: Mi 30.09.09 10:37 
Hallo pepper,

was deine Methoden, Events und BackgroundWorker machen war nun ein bisschen zu verschachtelt für mich :)

Vlt. wäre es besser, wenn du uns erklärst was du vor hast. Es gibt nämlich verschiedene Design-Pattern, wie Monitor-, Besucher- oder Erzeuger-Pattern, die vlt. für deinen Anwendungsfall gut geeignet sind und deine Probleme allgemeingültig lösen.

Gruß Daniel
pepper85 Threadstarter
Hält's aus hier
Beiträge: 4



BeitragVerfasst: Mi 30.09.09 21:13 
Hi,

da bin ich wieder.
Also nachdem ich nochmal nachgedacht habe, habe ich mein Konzept ein wenig vereinfacht.
ich mache nun in den Event kein Backgroundworker mehr uns somit habe ich nicht mehr das Problem mit Lock usw. Habe am Anfang gedacht es ist sinnvoller das Asynchron zu machen aber im endeffekt entstehen da mehr Probleme also Vorteile.
Arbeite sie jetzt doch hintereinander ab.

Also das Programm läuft jetzt. muss noch ein wenig den Code aufräumen und naml nen langzeittest machen aber sieht ansonsten gut aus. :)

Noch ne kleine Frage zu Events. Events sind nur sprungziele die keinen neuen Thread erzeugen oder?
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Mi 30.09.09 21:31 
Zitat:
Events sind nur sprungziele die keinen neuen Thread erzeugen oder?


Ja. Eine EventMethode läuft in dem Thread in dem der Event ausgelöst wird.

Ein EventHandler der am DoWork Event des BackgroundWorkers hängt würde zum Beispiel in einem anderen Thread laufen. Aber natürlich nur deshalb weil der Backgroundworker den Event explizit aus seinem internen Thread heraus wirft nicht deshalb weil es zufällig ein Event ist.