Re: Multi Threading Options

I concur. Your original description was not sufficient to deduce the desired behavior.
You do not need to synchronize the entire structure. We used this technique back in 1975
to avoid deadlock in a huge multiprocessor system. Each data structure had a "custodian"
thread (in those days, it meant a custodian process with shared memory), so what would
happen is that, in the context of your app, you sent either update requests (which change
the structure) or paint requests (which update the screen...and I don't mean WM_PAINT
messages, I mean a user-defined request). If you use PostMessage/PostThreadMessage, then
the requests are queued up. You could also choose to force a paint if no messages came
within some delta-T or after every N structure udpate requests. I've used similar
techniques to handle various kinds of asynchronous queueing. You can apply all sorts of
techniques to control the flow and updating frequency. In one case, I did the equivalent
of
if(!PeekMessage(...))
if(GetQueuedCompletionStatus(...,0))
MyProcessQueuedRequest(...);

which would, if there was no message pending, dequeue from an I/O completion port. This
let me have WM_TIMER messages in the queue. In another case, I would do for(i=0; i < n;
i++) to dequeue the first ten messages in the completion queue (see my essay on the use of
I/O Completion Ports on my MVP Tips site) that meant that there were no long delays on
user interaction but if nothing was happening we would try to flush the pending requests.
Kept the mouse alive in the main GUI thread while allowing floods of asynchronous updates
to the display data.
joe

On Wed, 01 Jun 2005 07:32:16 -0500, "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp>
wrote:

>Mark Randall wrote:
>> My problem is that I want to run a pretty hefty drawing routine on the other
>> thread - I really want to cause thread 2 to wait for data to finish being
>> written before it starts drawing the next image, and cause thread 2 to tell
>> thread one it can update again once it has finished drawing.
>
>In code such as this, where the threads are to "voluntarily" take turns,
>you have a third option. In addition to a mutex or crictical section,
>you can consider the use of an interthread message. When thread 1
>finishes updating the list it can post a message to thread 2 requesting
>a paint. And vice versa. Use PostMessage to a GUI thread,
>PostThreadMessage to a non-GUI thread. Example here:
>http://www.mvps.org/vcfaq/mfc/index.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages
Loading