.net: EndInvoke verlassen?

[cndg]

Hi!

Habe folgendes Problem, zu dem ich einfach keinen Ausweg finde: Ich führe an einer bestimmten Stelle im Programm einen EndInvoke-Call aus (um auf einen Rückgabewert zu warten) und bin mir darüber im Klaren, mit diesem Aufruf einen Deadlock verursachen zu können. Gibt es ein asynchrones EndInvoke/Invoke-Äquivalent, das sich non-blocking verhält und mir damit erlaubt, den Deadlock zu umgehen, das ich in einer Schleife so lange aufrufen kann, bis es einen Rückgabewert liefert?

mfg
cndg

[Biri]

hi !

sorry, kann dir da jetzt leider kein codebeispiel geben, aber soweit ich das jetzt weiß, ist der sinn von endinvoke ja, auf das ergebnis eines async. calls zu warten - also u.U. recht lange.

alle async methoden haben aber eine BeginAsync... methode, der kann man dann einen delegate übergeben (funktionszeiger), der automatisch aufgerufen wird, wenn die asynchrone methode beendet wurde - das ist ja auch sinn der sache: inzwischen was anderes machen, aber eine meldung bekommen, wenn die async. funktion fertig ist.

was genau willst du machen, wo du ein endinvoke benötigst ?

fg
-hannes

[cndg]

Hallo!

Ich werd mal ganz dezent versuchen, dir die genauen Umstände zu erläutern: Da gibt es einerseits den Main Thread, wo unter anderem die ganzen Steuerelemente erzeugt und betreut werden und dann hab ich da einen Background Thread, der unbedingt Zugriff auf die Steuerelemente des Main Threads benötigt, da er Änderungen unverzüglich an die Steuerelemente weitergeben muss.
Die Steuerelemente werden vom Background Thread aus via Invoke-Statements angesprochen. So weit so gut, ABER: Manche Invokes befinden sich innerhalb eines SyncLock-Blocks, da die Code-Teile, in denen sich diese Invokes befinden unbedingt in einem ausgeführt werden müssen, um Race Conditions in Verbindung mit dem Main Thread zu vermeiden.

Wenn nun der Main Thread in einer Event Handling Method auf ein vom Background Thread zufällig bereits in Anspruch genommenes SyncLock-Monitorobjekt stößt, wartet er, bis der Background Thread dieses Monitorobjekt wieder loslässt, was ihm aber in all jenen Fällen, in denen der Background Thread gerade mit einem Invoke innerhalb eines SyncLock-Blocks darauf wartet, dass der Main Thread die Event Handling Method endlich verlässt, verständlicherweise nie gelingen wird. Das führt dann eben unweigerlich zu einem Deadlock und die Mühle steht.

Das führte mich zu folgender Überlegung: Wenn doch das Invoke so tolerant gegenüber dem Main Thread wäre und nicht stur darauf beharren würde, unbedingt blockieren zu müssen, bis der Main Thread fertig ist. Und an diesem Punkt muss ich gestehen: Jetzt ist mir klar geworden, dass es eigentlich gar nix bringt, wenn das Invoke nachgibt, weil sich das Invoke noch immer innerhalb des SyncLock-Blocks befindet. Also eigentlich ist die Lage sogar irgendwie aussichtlos.

Bin irgendwie noch ratloser als zuvor.

mfg
cndg

[JackLemon]

wieso denn nicht einfach noch ein thread, dem du ganz einfach zb. ein delegate übergibst?