question about mutlithreading communitcation

One straightforward solution is a thread-safe
queue. You can make one of these by using a
critical-section and a std::queue.
Whenever you access the queue (read or write)
you lock the critical-section to ensure only
one thread is touching it at a time.
Have one queue passing events to the worker
thread, and another queue to receive results
back from the thread.

Quote:

Original post by c-mos Actually a worker thread cant receive messages sent with PostMessage.

If you're bound to the Windows platform Try PostThreadMessage instead.

Jans.

Thanks for the fast reply.
Would a named pipe too heavy for this kind of problem ?
But the Idea with the queue seems to be good. I fill the
queue with commands and drop them out in my rendering thread.
Do you have any other suggestions as well ?

regards,
c-mos

Quote:

Original post by c-mos Would a named pipe too heavy for this kind of problem ? But the Idea with the queue seems to be good. I fill the queue with commands and drop them out in my rendering thread.

This very much depends what you want to put into the queue. Rendering a scene by sending commands down a queue will introduce a per-message latency, lengthening the time it takes for a full frame to be presentable - this may or may not be suitable.

You might find that giving the thread a view onto the data, or even a queue of intermediate full-frame data, will give an abstraction with better performance.

Regards,
Jans.

This is related.

Hi Jansic,
that might be work but then I cant use worker threads instead I have to use
GUI-threads because worker threads dont have message handling.

What do you mean by

"You might find that giving the thread a view onto the data, or even a queue of intermediate full-frame data, will give an abstraction with better performance."

thanks,
c-mos

Quote:

Original post by phresnel This is related.

quoted for emphasis

Quote:

Original post by c-mos I cant use worker threads instead I have to use GUI-threads because worker threads dont have message handling.

If you take a look at the PostThreadMessage documentation you should find that ALL threads can accept messages. Windows discriminates between GUI & worker threads only by the presence of a window handle, they both still have message queues. For worker threads you'll need your own queue/messageloop anyway, whether you brew it yourself or use GetMessage...

Quote:

What do you mean by "You might find that giving the thread a view onto the data, or even a queue of intermediate full-frame data, will give an abstraction with better performance."

Crudely - instead of sending data to the thread, get the thread to read the data of its own accord; but since I don't know what you're doing I can't really advise.

Jans.

Thanks phresnel,
but your link doesn't help me absolutely in no way.
But I'm still open minded for any topic related
answers.

regards,
c-mos

Thanks for the advice Jansic,
I'll check that out.

regards,
c-mos

Quote:

Original post by c-mos Thanks phresnel, but your link doesn't help me absolutely in no way. But I'm still open minded for any topic related answers. regards, c-mos

It was about the situation that you hit explicitly without the need to be doing so. Just keep on writing near the end of the edit-box-line. That way, ppl can decide themselves what their most pleasing chars-per-line-threshold is. Abruptly breaking lines can be hard to follow :)

Ok,
I will keep that in mind ;)

Hi Jansic,
so finally I gave it a try and used a threadsafe queue.
I write commands from the main thread into a queue and
my worker thread processes these commands. So far so good,
that works. For testing purpose I rendered just a cube.
When I rotate the cube by mouse I can make a fast movement
and then watch patiently my cube rotating :D thats funny to watch
but its not "real time". I used a stl::queue and semaphore
for sync the queue read/write. I used the TRACE macro to show
when queue reads or writes data. It's interesting to see, that
when I stop moving the cube, there are lot of reads. While movement
it's almost even. write, read, write etc.
But something is slwoing down this.

regards,
c-mos

Quote:

Original post by c-mos Hi Jansic, so finally I gave it a try and used a threadsafe queue. I write commands from the main thread into a queue and my worker thread processes these commands. So far so good, that works. For testing purpose I rendered just a cube. When I rotate the cube by mouse I can make a fast movement and then watch patiently my cube rotating :D thats funny to watch but its not "real time". I used a stl::queue and semaphore for sync the queue read/write. I used the TRACE macro to show when queue reads or writes data. It's interesting to see, that when I stop moving the cube, there are lot of reads. While movement it's almost even. write, read, write etc. But something is slwoing down this. regards, c-mos

You
are invoking return
explicitly again which
makes it a
bit hard
too read as that way,
it doesn't fit the people's
prefered browser width :S ... ;)

Consider... if your badass enough... a lockless implementation. http://msdn.microsoft.com/en-us/library/ee418650%28VS.85%29.aspx

Also this thread made me lol. Hard.

What are you submitting to the queue? Really the scene/rendering should be independent of input unless you only want to render the scene when it has changed, but I'm guessing you don't want that. I would suggest you multithread by having one thread do any input processing and then you kick off multiple threads to walk the scene dispatching draw messages to the rendering thread.

This 'queue' you are using should be double buffered so that when the render thread is processing one queue the other threads are writing to the other queue.

One final note on the queue you can potentially end up with a lot of contention if there is a lock around the queue with multiple writer threads. If you find this is an issue (profiling shows worker threads spending time stalling waiting for the lock) there are a couple of options. You could either implement a multiple writer single lock-free queue using atomics. Alternatively each thread could have its own queue that get combined into one as a final step before passing it to the render thread.

Hi,
@Noggs,
actually there is the main thread (my window) and second thread
that hase the queue and does the opengl rendering. So in the
second thread there is just a while loop that reads the
messages from the queue. then i do the rendering. Maybe thats
the problem ?

regards,
c-mos