Concurrency, part way too many3: Concurrency and Windows

re: Concurrency, part way too many3: Concurrency and Windows

Ryan — Tue, 22 Mar 2005 21:47:00 GMT

ummm should this line "that thread is responsible for ensuring that the thread is constantly pumping messages for that thread" read

"that thread is responsible for ensuring that the thread is constantly pumping messages for that window"??

Ryan

re: Concurrency, part way too many3: Concurrency and Windows

CSS — Tue, 22 Mar 2005 22:23:00 GMT

We use a thread to read records from a database and inside the thread call sendmessage to let the UI thread know that the records are ready (so it can update it's display). The reason for using SendMessage is that it causes the data reader thread to block until the UI thread has responded to the SendMessage. We've never seen a problem with this code. Is there an issue we should know about?

re: Concurrency, part way too many3: Concurrency and Windows

Larry Osterman — Tue, 22 Mar 2005 22:34:00 GMT

CSS, as long as there are no interactions between your UI thread and the background thread you should be ok.

But if your UI thread ever synchronously attempts to get information from the background thread, you might have a problem. Your UI thread would be blocked waiting on the background thread, which would be blocked in SendMessage, waiting on the UI thread.

Blam.

re: Concurrency, part way too many3: Concurrency and Windows

Frederik Slijkerman — Wed, 23 Mar 2005 08:33:00 GMT

It is generally safer to use PostMessage, so the UI thread can retrieve data from the worker thread (and possibly enter critical sections) at its leisure.

re: Concurrency, part way too many3: Concurrency and Windows

Rick Brewster — Thu, 24 Mar 2005 00:39:00 GMT

Anyone that's really interested in how to do 'background' work while keeping the progress in the foreground should check out two things:

1. Two posts on my blog about it, "Progress Dialogs and Background Tasks" parts 1 and 2: http://blogs.msdn.com/rickbrew/archive/2005/01/28/362876.aspx and http://blogs.msdn.com/rickbrew/archive/2005/02/08/369484.aspx

2. Paint.NET v2.0's source code. Head straight for the MainForm.DoEffect() method and also refer to the BackgroundEffectRenderer class. http://www.eecs.wsu.edu/paint.net

Number 2 is especially interesting because the UI launches a dispatch thread which then launches 2-4 (or more -- depends on CPU count) worker threads. We initially ran into trouble because we wanted to preemptively stop and restart this in response to what configuration settings the user changed. So the UI thread would execute Stop(), then Join() ... then the dispatch thread would Stop() and Join() all the worker threads ... but if one of the threads was in the middle of raising a progress event ("i'm 13% done!") we would dealock because it was calling Invoke() back to the main UI thread. Awful circular deadlock.

It's written in C# but the concepts are the same. BeginInvoke() just maps to PostMessage() with a custom window message.

re: Concurrency, part way too many3: Concurrency and Windows

Dmitriy — Thu, 24 Mar 2005 16:13:00 GMT

Larry could please comments on some API(s), for example DestroyWindow, requirements to be called only from the thread that created the window.

re: Concurrency, part way too many3: Concurrency and Windows

Greg Dean — Tue, 29 Mar 2005 04:46:00 GMT

I could be mistaken but, in .NET the method Application.DoEvents() will keep the message pumps running.

Any comments?

Invoke vs BeginInvoke

Greg Young — Fri, 26 May 2006 03:52:33 GMT