I am looking to replace a framework from the ground up. It works as it is, but I've been tasked with understanding it, so I want to know if anyone else recognizes any glaring design issues that I could address in a re-write. Currently, the system works as follows:
- Server/producer very quickly inserts data into shared memory
- These data are organized as a series of ~10,000 fixed-length lists of structs in a circular buffer
- There may be between 0-25 clients for each of these 10,000 buffers
- Clients read every single update made to shared memory, decide whether or not they're interested, and process the data accordingly.
- Clients make sure to keep up with the circular buffer via a little arithmetic (am I behind, caught up, or have I been lapped by the server?)
- Client interest in a given update is determined by checking their own fixed-length array for a relevant pointer. If none is found, the update is skipped.
- If less than an arbitrary number of updates take place in the space it took for the client to catch up, then the client sleeps for a few microseconds.
Other than just removing the sleep, I feel like there's a lot of room for improvement in this design. The environment appears to be event-driven (new data comes in, stuff happens) yet there are polling mechanisms in play here. However, if having the producer remain unencumbered by any number of consumers is a top priority (which it is) I really don't know what an appropriate design is.
I envision some sort of system where clients can subscribe only to certain types of shared memory updates, to be notified when they arrive. This implies a third program - some kind of go-between for the producer and consumer. Surely this would be hugely resource intensive and not very efficient?
Any help would be appreciated, and of course I'll clarify anything I can to better present this question for an answer. =)