Problem with various BeginInvoke() calls

[Guest]

Could someone please explain the difference of (refer to example code below)
d.BeginInvoke("some text", null,null); //Alternative A
and
BeginInvoke( d, new object[] { "some text" } //Alternative B

Both calls causes asynchonous execution to begin at the address specified by
the delegate, and both calls returns an IAsyncResult, isn't that so?
However I've experienced that these calls can cause different program
behaviour.
Someone please explain.

**********Example code:******************
public delegate void SomeDelegate(string s);
private void SomeDelegateMethod(string s)
{
//Do whatever with the string
}

private void SomeOtherMethod()
{
SomeDelegate d = new SomeDelegate(SomeDelegateMethod);
//Alternative A:
d.BeginInvoke("some text", null,null);
//Alternative B:
BeginInvoke( d, new object[] { "some text" }
}
************************************

 

[Marc Gravell]

The form's .BeginInvoke will either push the work onto the UI thread (via
the event queue), or do it immediately (on the current thread) if it is
/already/ on the UI thread; the delegate's .BeginInvoke will perform the
work on a background (pool) thread.

If the underlying method attempts to work with UI controls then the
delegate's BeginInvoke will lead to exceptions due to thread affinity. If
you rely on e.g. opening a gate (semaphore, manualresetevent or whatever)
after the .BeginInvoke, then this may deadlock (itself, unusually) with the
form's approach (since the thread will never reach the code to open the
gate).

Marc

 

[Barry Kelly]

Could someone please explain the difference of (refer to example code below)
d.BeginInvoke("some text", null,null); //Alternative A
and
BeginInvoke( d, new object[] { "some text" } //Alternative B

This second BeginInvoke isn't a complete statement, BTW.

The two extra arguments to BeginInvoke (that are both null in your first
example) are (1) the delegate to call when the operation is complete
(AsyncCallback) and (2) the argument to pass as the value of the
AsyncState property on the IAsyncResult passed to the AsyncCallback in
(1).

The AsyncCallback pattern basically allows asynchronous programming
through manual conversion of code into continuation-passing style. The
idea is that you chain your operations through callbacks, so that each
operation calls an asynchronous method Begin*, passes in a callback
method, and the callback method calls the corresponding End* and itself
finishes in a Begin* (or not, if the whole task is finished).

-- Barry

 

[Marc Gravell]

Sorry - I meant to be clearer : the self-blocking scenario can only apply
when you call the form's .BeginInvoke from the UI thread itself...

i.e. (pseudo# ;-p) here we will probably stop at WaitForGate() for quite
some time...

ManualResetEvent gate = {blah};
void MainMethod() {
iar = BeginInvoke(SomeFunc);
gate.Set();
iar.EndInvoke();
}

void SomeFunc() {
gate.WaitOne();
// do something interesting
}

 

[Andreas Mueller]

Could someone please explain the difference of (refer to example code below)
d.BeginInvoke("some text", null,null); //Alternative A
and
BeginInvoke( d, new object[] { "some text" } //Alternative B

Both calls causes asynchonous execution to begin at the address specified by
the delegate, and both calls returns an IAsyncResult, isn't that so?
However I've experienced that these calls can cause different program
behaviour.
Someone please explain.

**********Example code:******************
public delegate void SomeDelegate(string s);
private void SomeDelegateMethod(string s)
{
//Do whatever with the string
}

private void SomeOtherMethod()
{
SomeDelegate d = new SomeDelegate(SomeDelegateMethod);
//Alternative A:
d.BeginInvoke("some text", null,null);
//Alternative B:
BeginInvoke( d, new object[] { "some text" }
}
************************************

The following link helped me to understand this issue:

http://www.codeproject.com/csharp/begininvoke.asp

 

[Guest]

Thanks. That article does the trick.
Not very obvious that there is such a difference though.