pepper85 - Di 29.09.09 23:34
Titel: lock ist zu langsam

---

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 - Di 29.09.09 23:44

---

:welcome: !

pepper85 hat folgendes geschrieben :

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.

pepper85 hat folgendes geschrieben :

[...]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 - 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 - 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 - 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 - 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 - 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.