Using EndInvoke From within an AsyncCallback?

[Doug Thews]

I've been working on some samples that use BeginInvoke/EndInvoke. In one
example, I call BeginInvoke and pass it an AsyncCallback function pointer.
I was messing around with ReaderWriterLoc ks and noticed that if I did this,
it worked (please ignore the lack of try ... catch blocks, because I cut
down the code to be more brief - I have a try...catch surround the
AcquireWriterLo ck method):
----------
myLock.AcquireW riterLock(1000) ;
iasResult = fprUIUpdate.Beg inInvoke(strBuf fer,null,null);

// Some other async operations can be done here

// Get the results of the delegate using EndInvoke. This will block
// execution of this thread until the delegate invoked completes
fprUIUpdate.End Invoke(iasResul t);
myLock.ReleaseW riterLock();
---------
But, if I do it this way, the WriterLock never gets cleared, even though the
statement gets executed in the AsyncCallback method:
---------
myLock.AcquireW riterLock(1000) ;
iasResult = fprUIUpdate.Beg inInvoke(strBuf fer,new
AsyncCallback(M essageUpdatedCa llBack),null);

// Some other async operations can be done here

public void MessageUpdatedC allBack(System. IAsyncResult Result)
{
// Get the results of the delegate using EndInvoke
fprUIUpdate.End Invoke(iasResul t);

// Operation completed, we can now give up the buffer lock
myLock.ReleaseW riterLock();
}
---------

I've validated that the myLock.ReleaseW riterLock method gets called in the
AsyncCallback routine, but for some reason the very next time it gets
checked, it comes back as locked. BUT, if I move it all back into the
thread and don't use callbacks, the same logic seems to work fine.

Is myLock no longer the same object reference (even though it's all in the
same class) because it's now inside an AsyncCallback function? I made
myLock a static variable inside the class to make sure that this wasn't the
problem, but no luck.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

[Jon Skeet [C# MVP]]

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

I've been working on some samples that use BeginInvoke/EndInvoke. In one
example, I call BeginInvoke and pass it an AsyncCallback function pointer.
I was messing around with ReaderWriterLoc ks and noticed that if I did this,
it worked (please ignore the lack of try ... catch blocks, because I cut
down the code to be more brief - I have a try...catch surround the
AcquireWriterLo ck method):
----------
myLock.AcquireW riterLock(1000) ;
iasResult = fprUIUpdate.Beg inInvoke(strBuf fer,null,null);

// Some other async operations can be done here

// Get the results of the delegate using EndInvoke. This will block
// execution of this thread until the delegate invoked completes
fprUIUpdate.End Invoke(iasResul t);
myLock.ReleaseW riterLock();
---------
But, if I do it this way, the WriterLock never gets cleared, even though the
statement gets executed in the AsyncCallback method:
---------
myLock.AcquireW riterLock(1000) ;
iasResult = fprUIUpdate.Beg inInvoke(strBuf fer,new
AsyncCallback(M essageUpdatedCa llBack),null);

// Some other async operations can be done here

public void MessageUpdatedC allBack(System. IAsyncResult Result)
{
// Get the results of the delegate using EndInvoke
fprUIUpdate.End Invoke(iasResul t);

// Operation completed, we can now give up the buffer lock
myLock.ReleaseW riterLock();
}
---------

I've validated that the myLock.ReleaseW riterLock method gets called in the
AsyncCallback routine, but for some reason the very next time it gets
checked, it comes back as locked. BUT, if I move it all back into the
thread and don't use callbacks, the same logic seems to work fine.

Hang on - that seems very dodgy code. You've got two different threads
trying to acquire the writer lock, and a different thread releasing it
again. I suspect if you put a try/catch round the ReleaseWriterLo ck
call, you'll find that it's throwing an exception because the thread
doesn't own the lock.

ReaderWriterLoc k just isn't meant for this kind of operation - you'll
need to create your own equivalent if you want to be able to acquire
and release the lock from different threads.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Doug Thews]

OK, I get it. The AsyncCallback method is not in the same thread as this
worker thread, even though its method is in the thread's class. It belongs
to the thread of fprUIUpdate, right? That makes perfect sense now.

What I was attempting to do was hold a lock until the UI Update operation
was completed, and I thought I could do it with an Async callback. Instead,
I just reverted to calling EndInvoke right after BeginInvoke in the worker
thread and then release the lock. Works like a champ!

Thanks for the explanation.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** **************@ msnews.microsof t.com...

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

I've been working on some samples that use BeginInvoke/EndInvoke. In one
example, I call BeginInvoke and pass it an AsyncCallback function
pointer.
I was messing around with ReaderWriterLoc ks and noticed that if I did
this,
it worked (please ignore the lack of try ... catch blocks, because I cut
down the code to be more brief - I have a try...catch surround the
AcquireWriterLo ck method):
----------
myLock.AcquireW riterLock(1000) ;
iasResult = fprUIUpdate.Beg inInvoke(strBuf fer,null,null);

// Some other async operations can be done here

// Get the results of the delegate using EndInvoke. This will block
// execution of this thread until the delegate invoked completes
fprUIUpdate.End Invoke(iasResul t);
myLock.ReleaseW riterLock();
---------
But, if I do it this way, the WriterLock never gets cleared, even though
the
statement gets executed in the AsyncCallback method:
---------
myLock.AcquireW riterLock(1000) ;
iasResult = fprUIUpdate.Beg inInvoke(strBuf fer,new
AsyncCallback(M essageUpdatedCa llBack),null);

// Some other async operations can be done here

public void MessageUpdatedC allBack(System. IAsyncResult Result)
{
// Get the results of the delegate using EndInvoke
fprUIUpdate.End Invoke(iasResul t);

// Operation completed, we can now give up the buffer lock
myLock.ReleaseW riterLock();
}
---------

I've validated that the myLock.ReleaseW riterLock method gets called in
the
AsyncCallback routine, but for some reason the very next time it gets
checked, it comes back as locked. BUT, if I move it all back into the
thread and don't use callbacks, the same logic seems to work fine.

Hang on - that seems very dodgy code. You've got two different threads
trying to acquire the writer lock, and a different thread releasing it
again. I suspect if you put a try/catch round the ReleaseWriterLo ck
call, you'll find that it's throwing an exception because the thread
doesn't own the lock.

ReaderWriterLoc k just isn't meant for this kind of operation - you'll
need to create your own equivalent if you want to be able to acquire
and release the lock from different threads.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

OK, I get it. The AsyncCallback method is not in the same thread as this
worker thread, even though its method is in the thread's class. It belongs
to the thread of fprUIUpdate, right? That makes perfect sense now.
I think you're making a mistake associating threads with objects -
they're completely orthogonal concepts.
What I was attempting to do was hold a lock until the UI Update operation
was completed, and I thought I could do it with an Async callback. Instead,
I just reverted to calling EndInvoke right after BeginInvoke in the worker
thread and then release the lock. Works like a champ!

If you're going to call EndInvoke immediately after BeginInvoke, why
bother doing it asynchronously at all? Just call Invoke instead.

Then again, I'm still not entirely sure what you're doing - what is the
lock for here?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Doug Thews]

I'm just writing some example code, so please don't worry about the "why
would you do it like that?" design questions. I'm just trying to
familiarize myself with what works and what doesn't.

OK, what I've got is a class with a method in it that becomes my worker
thread. It's sole goal is to the operation and send back a string back to
the UI textbox for display (hence the need for a delegate). So, in the main
thread I instantiate an instance of this class and then spin a thread off
pointing to this method (I hate examples where the thread code is inside the
Form class, it doesn't tell you much about who can call what and so on - as
evidenced by my work with delegates in the past).

What I want to gain familiarity with the ReaderWriterLoc k method, so I use
it to gain a lock on a static string that will be used to send to the
UIUpdate. I lock it when I Invoke the UIUpdate and want to unlock it when
the UIUpdate is finished. Yes, I know that I wouldn't do this in a
production app, but I want to familiarize myself with the ReaderWriterLoc k,
and what better way than through a UI example (and not some stupid console
example that doesn't prove anything).

Anyway, you didn't answer my last question. The AsycCallback method is
running in the UI thread and not the worker thread, right? And yes, I could
just call Invoke on the instance of the Form from the worker thread, but
I've already written examples using Invoke - now I want to write examples
using BeginInvoke & EndInvoke to see how they interoperate. Remember, these
are examples, so they serve no useful purpose other than to educate.

Thanks in advance for your help.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

OK, I get it. The AsyncCallback method is not in the same thread as this
worker thread, even though its method is in the thread's class. It
belongs
to the thread of fprUIUpdate, right? That makes perfect sense now.

I think you're making a mistake associating threads with objects -
they're completely orthogonal concepts.

What I was attempting to do was hold a lock until the UI Update operation
was completed, and I thought I could do it with an Async callback.
Instead,
I just reverted to calling EndInvoke right after BeginInvoke in the
worker
thread and then release the lock. Works like a champ!

If you're going to call EndInvoke immediately after BeginInvoke, why
bother doing it asynchronously at all? Just call Invoke instead.

Then again, I'm still not entirely sure what you're doing - what is the
lock for here?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

I'm just writing some example code, so please don't worry about the "why
would you do it like that?" design questions. I'm just trying to
familiarize myself with what works and what doesn't.

OK, what I've got is a class with a method in it that becomes my worker
thread. It's sole goal is to the operation and send back a string back to
the UI textbox for display (hence the need for a delegate). So, in the main
thread I instantiate an instance of this class and then spin a thread off
pointing to this method (I hate examples where the thread code is inside the
Form class, it doesn't tell you much about who can call what and so on - as
evidenced by my work with delegates in the past).
Right.
What I want to gain familiarity with the ReaderWriterLoc k method, so I use
it to gain a lock on a static string that will be used to send to the
UIUpdate. I lock it when I Invoke the UIUpdate and want to unlock it when
the UIUpdate is finished. Yes, I know that I wouldn't do this in a
production app, but I want to familiarize myself with the ReaderWriterLoc k,
and what better way than through a UI example (and not some stupid console
example that doesn't prove anything).
I'm not sure it's much of a help here though - there's no real need to
lock, and in practice, locking things for arbitrary amounts of time is
a bad idea. I'm just not sure how much you're actually
proving/learning.
Anyway, you didn't answer my last question. The AsycCallback method is
running in the UI thread and not the worker thread, right?
That depends on what fprUIUpdate is. Assuming it's a delegate then no,
it'll be running on a threadpool thread.
And yes, I could
just call Invoke on the instance of the Form from the worker thread, but
I've already written examples using Invoke - now I want to write examples
using BeginInvoke & EndInvoke to see how they interoperate. Remember, these
are examples, so they serve no useful purpose other than to educate.

There's a big difference between calling a delegate's
BeginInvoke/EndInvoke and calling BeginInvoke/EndInvoke on a control.
When using someDelegate.Be ginInvoke, the delegate and callback end up
being invoked on a thread pool thread. When using a control, the
delegate is called on the UI thread. You also don't need to use
EndInvoke when using BeginInvoke on a control, but you *do* need it
when calling it on a delegate.

There are 3 separate concepts here for calling code in a different
thread:

1) Starting a new thread with a ThreadStart
2) Calling Invoke/BeginInvoke on a control
3) Calling BeginInvoke on a delegate

I think it's worth separating them out very carefully in your mind.
I haven't pointed you to my threading guide yet (unusually, for me!) -
it's at http://www.pobox.com/~skeet/csharp/threads

See if that helps you out at all.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Doug Thews]

Hey, thanks for the link. So, the AsyncCallback method runs in another
thread in the thread pool, and not in the same thread as the actual worker
thread that's running, right? That's why putting a lock in the
AsyncCallback method doesn't work, because THAT thread doesn't have a lock
(the other worker thread does - so that's why an exception is generated in
the AsyncCallback method). Do I have it right?

BTW ... I think it's a good idea to write an article from a beginner's
perspective, and I plan to do so - thanks to your help. What I've found is
that there are a lot of thread articles out there, and NONE OF THEM talk
about the dangers of Thread.Abort(), how to safely update the UI (because
most of them just are console test apps - pretty worthless), and none of
them talk about using delegates off of instantiated objects (all of the
examples I've seen, just put the thread code into the Main or Form class -
again, not realistic).

Thanks in advance for your pointers.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

I'm just writing some example code, so please don't worry about the "why
would you do it like that?" design questions. I'm just trying to
familiarize myself with what works and what doesn't.

OK, what I've got is a class with a method in it that becomes my worker
thread. It's sole goal is to the operation and send back a string back
to
the UI textbox for display (hence the need for a delegate). So, in the
main
thread I instantiate an instance of this class and then spin a thread off
pointing to this method (I hate examples where the thread code is inside
the
Form class, it doesn't tell you much about who can call what and so on -
as
evidenced by my work with delegates in the past).

Right.

What I want to gain familiarity with the ReaderWriterLoc k method, so I
use
it to gain a lock on a static string that will be used to send to the
UIUpdate. I lock it when I Invoke the UIUpdate and want to unlock it when
the UIUpdate is finished. Yes, I know that I wouldn't do this in a
production app, but I want to familiarize myself with the
ReaderWriterLoc k,
and what better way than through a UI example (and not some stupid
console
example that doesn't prove anything).

I'm not sure it's much of a help here though - there's no real need to
lock, and in practice, locking things for arbitrary amounts of time is
a bad idea. I'm just not sure how much you're actually
proving/learning.

Anyway, you didn't answer my last question. The AsycCallback method is
running in the UI thread and not the worker thread, right?

That depends on what fprUIUpdate is. Assuming it's a delegate then no,
it'll be running on a threadpool thread.

And yes, I could
just call Invoke on the instance of the Form from the worker thread, but
I've already written examples using Invoke - now I want to write examples
using BeginInvoke & EndInvoke to see how they interoperate. Remember,
these
are examples, so they serve no useful purpose other than to educate.

There's a big difference between calling a delegate's
BeginInvoke/EndInvoke and calling BeginInvoke/EndInvoke on a control.
When using someDelegate.Be ginInvoke, the delegate and callback end up
being invoked on a thread pool thread. When using a control, the
delegate is called on the UI thread. You also don't need to use
EndInvoke when using BeginInvoke on a control, but you *do* need it
when calling it on a delegate.

There are 3 separate concepts here for calling code in a different
thread:

1) Starting a new thread with a ThreadStart
2) Calling Invoke/BeginInvoke on a control
3) Calling BeginInvoke on a delegate

I think it's worth separating them out very carefully in your mind.
I haven't pointed you to my threading guide yet (unusually, for me!) -
it's at http://www.pobox.com/~skeet/csharp/threads

See if that helps you out at all.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Richard Blewett [DevelopMentor]]

The callback *may* run on the same worker thread as the method invocation but isn't guaranteed to (my guess is at async method end the callback simply gets put ont he thread pool queue again - but i haven't checked the implementation in rotor to check whether this is true.

Regards

RIchard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<uE************ *@tk2msftngp13. phx.gbl>

Hey, thanks for the link. So, the AsyncCallback method runs in another
thread in the thread pool, and not in the same thread as the actual worker
thread that's running, right? That's why putting a lock in the
AsyncCallback method doesn't work, because THAT thread doesn't have a lock
(the other worker thread does - so that's why an exception is generated in
the AsyncCallback method). Do I have it right?

BTW ... I think it's a good idea to write an article from a beginner's
perspective, and I plan to do so - thanks to your help. What I've found is
that there are a lot of thread articles out there, and NONE OF THEM talk
about the dangers of Thread.Abort(), how to safely update the UI (because
most of them just are console test apps - pretty worthless), and none of
them talk about using delegates off of instantiated objects (all of the
examples I've seen, just put the thread code into the Main or Form class -
again, not realistic).

Thanks in advance for your pointers.

[Doug Thews]

I have a feeling it doesn't, since the lock doesn't seem to work - giving me
the impression that I'm not inside the worker thread (otherwise I'd have
access to it). But, I'm guessing that I'm a lot closer to understanding the
problems than I was yesterday. Thanks for the tips.

BTW ... You do understand about the articles that I'm talking about. Now
that I've worked with this stuff a little, I can see that the beginner
articles are seriously lacking in some content (not to mention they all use
a simple console app & Console.Write() as examples - not exactly useful
stuff). I have yet to find anything close to what I've already found out
with my own example code and return posts from this newsgroup. Thanks a
bunch!

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Richard Blewett [DevelopMentor]" <ri******@devel op.com> wrote in message
news:Ou******** *****@TK2MSFTNG P11.phx.gbl...

The callback *may* run on the same worker thread as the method invocation
but isn't guaranteed to (my guess is at async method end the callback
simply gets put ont he thread pool queue again - but i haven't checked the
implementation in rotor to check whether this is true.

Regards

RIchard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<uE************ *@tk2msftngp13. phx.gbl>

Hey, thanks for the link. So, the AsyncCallback method runs in another
thread in the thread pool, and not in the same thread as the actual worker
thread that's running, right? That's why putting a lock in the
AsyncCallback method doesn't work, because THAT thread doesn't have a lock
(the other worker thread does - so that's why an exception is generated in
the AsyncCallback method). Do I have it right?

BTW ... I think it's a good idea to write an article from a beginner's
perspective, and I plan to do so - thanks to your help. What I've found is
that there are a lot of thread articles out there, and NONE OF THEM talk
about the dangers of Thread.Abort(), how to safely update the UI (because
most of them just are console test apps - pretty worthless), and none of
them talk about using delegates off of instantiated objects (all of the
examples I've seen, just put the thread code into the Main or Form class -
again, not realistic).

Thanks in advance for your pointers.

[Jon Skeet [C# MVP]]

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

Hey, thanks for the link. So, the AsyncCallback method runs in another
thread in the thread pool, and not in the same thread as the actual worker
thread that's running, right?
I think it's *likely* to run in the same thread that the delegate runs
in. It won't be running in the thread which calls BeginInvoke.
That's why putting a lock in the
AsyncCallback method doesn't work, because THAT thread doesn't have a lock
(the other worker thread does - so that's why an exception is generated in
the AsyncCallback method). Do I have it right?
Yup.
BTW ... I think it's a good idea to write an article from a beginner's
perspective, and I plan to do so - thanks to your help. What I've found is
that there are a lot of thread articles out there, and NONE OF THEM talk
about the dangers of Thread.Abort()
That's a definite "TBD" in my own article at the moment.
how to safely update the UI (because
most of them just are console test apps - pretty worthless), and none of
them talk about using delegates off of instantiated objects (all of the
examples I've seen, just put the thread code into the Main or Form class -
again, not realistic).

Actually, almost *all* threading articles that I've seen talk about how
to safely update the UI. They do tend to usee delegates in the form
rather than existing class, but I think that's a more "general C#
understanding" than threading issue. I'll change some of my examples to
use delegates in another class though.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too