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