asynchron oder doch nicht?????

[dicabor]

guten Morgen!

schon eine weile beschäftige ich mich (ich versuche es:-))
mit asynchronen delegaten. Ziel ist es eine dll die in die DB schreibt gleichzeitig zu beballern. genauso schreibt sie auf die Console und das ist es was ich folgendermaßen ausprobiert habe.
#########################################
<PRE>Main
{
..........
InvokerClass Io = new InvokerClass()
Io.Run();
}
########################################
class Invokerclasss
{
........
public void Run()
{
WorkerClass[] Wo = new WorkerClass[5];

for(int i = 0; i<5;i++)
{
Wo[i] = new WorkerClass( i );
Wo[i].WriteOnConsole();
}
}
}
######################################
class WorkerClass()
{
private int counter = 0;

private delegate void ASDeleGate();
private ASDeleGate AS_DeleGate;

public WorkerClass(int i)
{
this.counter = i;
}

public void Write on Console()
{
// hier starte ich einen Timer mit einem interval von 1000 msec.
// welcher die Methode DoWork aufruft
}

private void DoWork(...........,..........)
{

AS_DeleGate = new ASDeleGate(Run);
ar = AS_DeleGate.BeginInvoke(null,null);
AS_DeleGate.EndInvoke(ar);

}

private void Run()
{
// hier lege ich mir eine object meiner dll an und lasse sie //auch die console schreiben mit dem wert von Counter
}
}
</PRE>

Die Ausgabe auf der Console ist immer sortiert
0 //ist der Wert von counter der übergeben wird
1
2
3
4

und nie asynchron zum andern platzt die ausgabe einfach so in den monitor und erscheint nichtnacheinander so wie ich mir das dachte.
kann es sein das ich hier garkeine asynchrone geschichte habe und die einzelnen Wo-Objecte nicht gleichzeitig auf der dll rumhacken??

gruß dica

[Andreas Kosch]

Hallo,

díe Ursache für dieses Problem liegt darin, dass BeginInvoke und EndInvoke hintereinander aufgerufen werden:
<pre>
AS_DeleGate = new ASDeleGate(Run);
ar = AS_DeleGate.BeginInvoke(null,null);
AS_DeleGate.EndInvoke(ar);
</pre>
Es kann aber nur dann wie gewünscht funktionieren, wenn die aufrufende Stelle <b>nach</b> dem Aufruf von BeginInvoke "normal" weiterlaufen kann und <b>nicht</b> sofort wieder auf einen Stopper a la EndInvoke trifft. Statt dessen muss das Ende des asynchronen Methodenaufrufs in der aufgerufenen Delegate-Methode (Callback-Methode) selbst ausgewertet werden. Da diese Callback-Methoden implizit in einem eigenen Thread läuft, fällt es dort nicht auf, dass der "Stopper" auf das Ende des asynchronen Methodenaufrufs wartet.

Am Beispiel eines asynchron aufgerufenen Web Services sieht das so aus:
<pre>
private void LogAction(string sAction)
{
string sTxt;
sTxt = string.Format("{0}: {1}", System.Environment.TickCount.ToString(), sAction);
ListBox1.Items.Add(sTxt);
}
private void OSCreditCardCheckCallback(IAsyncResult iAR)
{
string sTxt = ((localhost.ServiceAsync)iAR.AsyncState).EndOSCred itCardCheck(iAR);
LogAction("Ergebnis: " + sTxt);
}

private void Button2_Click(object sender, System.EventArgs e)
{
ListBox1.Items.Add("-------------------");
ListBox1.Items.Add("Assynchoner Aufruf:");
LogAction("Instanz wird vom Web Service angefordert");
localhost.ServiceAsync aWS = new localhost.ServiceAsync();
IAsyncResult iAR;
LogAction("Methode BeginOSCreditCardCheck wird aufgerufen...");
iAR = aWS.BeginOSCreditCardCheck(textBox1.Text, new System.AsyncCallback(OSCreditCardCheckCallback), aWS);
LogAction("...Methodeaufruf BeginOSCreditCardCheck fertig.");
StatusBar1.Text = "Fertig.";
}
</pre>
Die Protokollmeldungen in der Listbox machen auf einen Blick deutlich, dass die aufrufende Stelle tatsächlich "weitergelaufen" ist, obwohl der aufgerufene Web Service noch nicht fertig war.
&#10