Back to General and Gameplay Programming

Inter-thread communication

Max Optional · 2014-07-24T00:08:51

tl;dr - in short, this is a question of how to best implement my own version of PostThreadMessage(). More precisely, my target problem right now is communication between the input and render threads in the context of a GUI. I'd like this very same logic to be extensible to communication between the input and game logic threads, and load and render threads. I've kind of settled on a fairly simple counter-based method as I've come along, as it just works. My assumptions are: - I don't want to use a locking mechanism - instead I either use polling in the render thread if running in real-time mode, or signaling via something like a waitable object to force a refresh, if not running in real-time mode. This bit I'm somewhat worried about as I'm not yet sure as to how portable it is. - I'd like the communication scheme to be extensible to any many-to-one thread model where many threads can send messages to one target thread With this in mind the best (and so far only, really) way I've managed think of is a FIFO stack with each sender thread having its own dispatch queue and a write marker that points into a circular buffer (eg the stack). The receiving thread then reads everything from its respective read marker up to the write marker at each iteration (or when notified). There is no synchronization between the two threads other than a possible SetEvent() called by the sender if the render thread doesn't already poll in a tight loop. So far this has been a fairly straightforward and foolproof approach. The primary problem I see here is guesstimating the size of the message buffer and, in particular, what to do when an overflow occurs. Before going about reallocating memory to fit more messages I figured it'd make sense to actually see if there might be more trickery involved in the way Windows does it (yeah, that was a question). Also, in a way it feels a bit like a hack, even though it works :)

General and Gameplay Programming Programming

Started by irreversible July 16, 2014 10:46 PM

20 comments, last by Hodgman 9 years, 8 months ago

King Mir

2,506

July 23, 2014 02:38 PM

Regarding volatile, IMHO unless you're writing a device driver, the only place you should use volatile is inside the implementation of std::atomic (or similar reinvented wheel).

Even std::atomic shouldn't be using volatile. You really need hardware memory barriers for atomic operations, except in cases where the basic load and store instructions provide sufficient synchronization guarantees. You also need compiler hooks to ensure that the more lax operations are respected, including ubiquitous acquire-release semantics.

Hodgman

52,717

July 24, 2014 12:08 AM

Regarding volatile, IMHO unless you're writing a device driver, the only place you should use volatile is inside the implementation of std::atomic (or similar reinvented wheel).
Even std::atomic shouldn't be using volatile. You really need hardware memory barriers for atomic operations, except in cases where the basic load and store instructions provide sufficient synchronization guarantees. You also need compiler hooks to ensure that the more lax operations are respected, including ubiquitous acquire-release semantics.

True - but for some reason MS decided that the Interlocked intrinsics (which act as runtime and compile-time memory fences) can only be passed volatile integers... :/
So you'll definitely see the keyword used on a Windows/MSVC implementation ;-)

. 22 Racing Series .

Inter-thread communication

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Inter-thread communication

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines