Connecting UI- and Worker-Threads

[Incubbus]

I am wonderin about what could be the best way to connect an worker thread with an UI thread in the way, that the UI thread delegates an assignment to the worker which in case signals that he has finished and hands over the result to the UI thread again - so that the UI can be updated based on those results...

I want to do it only with the native stuff I have (no boost, no not nothin)...

I googled around and couldnt get the right searches up (as it always gave me results where they used CLR/MFC/C# solutions like Begin.Invoke or something like this)...

The possibilities I thought about would contain a queue which would be polled for, or a WM_xxx <- but somehow this does not feel right:/...


How would You do it only with the basic stuff we are given?...

[guestgulkan]

The WaitForSingleObject winapi function should work for this.

See here
http://127.0.0.1:47873/help/1-6980/ms.help?method=page&id=E37EBFF7-B44E-469D-81AB-7A6BD1A0C822&product=VS&productversion=100&locale=en-US&topiclocale=EN-US&topicversion=85&SQM=2

[Incubbus]

The link does not work, but as far as I do remember, WaitForSingleObject() is a blocking call, which is deadly for the UX/UI...

Edit: If I specify a timeout, wouldn´t that be the same as polling the usual way?...

[guestgulkan]

I read your post wrong :-) - I thought you were asking for a blocking call.

I wonder if a callback function would work? (I think I'll try it out).

[Incubbus]

If I call a function from the worker thread to update the UI, wouldn´t this defeat the purpose of the UI-thread?^^

All updates to the UI should only be made from the UI-thread

[guestgulkan]

I'm just running through the ways I can think of:
Next up:

PostMessage - the worker thread posts a completion message (to the UI window) - the worker thread can then quit because the PostMessage is non-blocking.

[Incubbus]

I think that could be nearly the same as (which I prefer):

if(PeekMessage([...] PM_REMOVE))
{
//process messages
}
else
{
//Poll for data...
}

[Incubbus]

Does anyone else have another solution, or knows which is best?...

[kbw]

You're question is very general and without more information on the kind of work you want to do it's difficult to be more specific than what's already been suggested.

Having said that, ACE uses workers with queues. You submit a task to the thread's queue and it's processed in turn. That seems like a reasonable basic approach to me.

You've not mentioned how you're prepared to "know" when the work is done (you've already discounted waiting).

[Incubbus]

My connection is receiving data which shall be submitted to the Dialog I did create... so the worker thread is receiving and the UI thread shall update the UI...

I can signale this via an message or by increasing a semaphore or something like that... Or let the UI-message-function poll for it...

What´s ACE?...

[kbw]

The worker thread can populate some shared data structure and notify you of it's arrival with PostMessage; that's one way.

ACE?
http://www.cs.wustl.edu/~schmidt/ACE.html

[Incubbus]

looks like some kind of third party library... What I don´t want to use... but it is interesting to read about it, so i can try to do some stuff on my own (it´s more fun to reinvent the wheel, for me^^)...

[kbw]

I wouldn't recommend ACE for small projects, but on large distributed systems, it has a place.

It sounds like rolling your own is the way to go at this stage.

[Incubbus]

Yay,.. But thanks to both of You...

[Incubbus]

If anyony is interested, and for persons who may search for and find this topic: I came up with the idea of APCs (Asynchronous Procedure Calls)... which may fit better to my needs...

There is one good basic article about this topic (besides the MSDN ref on this): http://weblogs.asp.net/kennykerr/archive/2007/12/11/parallel-programming-with-c-a-new-series.aspx