Asynchronous BeginInvoke GUI update order

Hot Topic

Cannot uninstall WDS v2.6.5 (5378) under XP SP2
Where do images go?
Is it possible to swap in DataGrid?
Socket programming
WebBrowser events question
.NET 2.0 Windows Service
Unable to update the dependencies of the project
how to retrive the Application filename.exe
Just Learning how-to-use C# - Please can these warnings be explained
Problem with PInvoke finding/loading unmanaged DLL

Visual C#

Deleting Control form my from
using Streams
Custom MenuItem problem when used in ContextMenu
float datatype gives different result for debug/release build. Bug?
Using online content with iHD
Unrecognized configuration section 'connectionStrings'
GDI form transparency problem
How do I use XSD in 2005
Threaded Controls
multidimensional array trouble

Asynchronous BeginInvoke GUI update order

Yes/No question for the experts:

If I only have thread A and B (thread A being the GUI thread), and B calls several BeginInvoke's in a row to 'Post' messages to thread A, is the order in which thread B updates thread A guaranteed to be preserved

I can write a simple app that would give an answer, but I prefer to hear the answer from the GURUs just to make sure.

Thanks
-Kevin



Answer this question

Asynchronous BeginInvoke GUI update order

  • Anand Desai

    Thank you for the reply. I am surprised, I thought they would be in order, as long as they are all coming from the same source thread. I am using C# 2.0, and what I am doing is more involved than what I was asking. However, I was still interested to know the answer for the simple case I described above.

    My technique consists of a GUI thread (thread A) that starts a separate thread (B). Thread B is a thread that runs a 'for' loop and starts a background worker upon each loop. Thread B also asynchronously updates thread A when it starts a background worker. All tests (so far) show that B updates A in a consistent 1 to n order, but I will take your word that you are correct, considering your credentials :).

    The background worker threads do the dirty work (generating images), and they also asynchronously update thread A when they are complete. I understand that since some may take longer than others and since they are each updating thread A from different threads, the order from which they were started is not preserved. That one is obvious but does not pose a problem with my design.

    One thing I found that I thought was interesting was the thread on which the background worker RunWorkComplete event handler takes place. My tests showed that if the worker is started on the GUI thread, the handler will also run on the GUI thread. However, if the worker is started on a separate thread (say thread B), then the worker will execute on thread C but the handler will run on a new thread D, not on thread B where it was started.

    Anyways, my design allows me to specify N number of concurrent background workers, allowing me to take advantage of multi-processor and dual-core computers.

    Thanks again for your answer.


  • tulip-pcsc

    No. These are not guaranteed to be in the same order you called them in.  Are you using C# 2.0   If so, you might consider using the background worker component. It still wont guarantee your update execution order, but it will do some of the dirty work for you.

  • Asynchronous BeginInvoke GUI update order
Answer this question