My current design is that the writer process has its original display in private memory, then opportunistically copies to the shared memory section if it finds that no processes are currently reading (checking an event object). If they are, it sets a second event object indicating that no other readers should begin reading and then returns to whatever else it was doing. It will try again after it has performed another internal update.
This will necessarily mean that the readers will at some point be "locked out" from updates. I think this is the most appropriate design for remoting a display, but will probably need a different design for remoting audio, where stalls are much more obvious.
