I have a weird question. There is something I clearly don't know about low level programming and memory.
My experience with comm protocols, over defective hardware ports and bad phone lines led to some adaptive dynamic code.
If I have a producer guard tied to a bit (2 actually) status for the consumer then all I need to know is:
The memory write lag to unlock after consuming the data. The timing is closely related to setting the in-progress bit and the process time of the producer.
The approximate amount of time in both loops.
The cost of the producer checking the guard (again) before writing because it is costly. It must do a Next if the block was processed after all.
How much "fixed" lag have I created to avoid a consumer memory write timing error?
It's a little trick where both sides know the token (mutex) or lock bit expires after X ms. The producer sets it's exclusive data ready bit. The consumer has exclusive in progress and completed bits. Normally the time to detect the producer data ready bit and spinning are the issue.
Where the consumer fails or is slow the producer gets control of the buffer again. It can retry or apply more advanced handling. A timeout right? It can happen.
Therefore... Buffer overruns and or dropped bits (the issue) did not cause a problem. It's a mathematical characteristic of timing.
Well... restarts of crashed consumers were complex but that's off topic. The algorithm was fine.
SO........ I bet this doesn't work with static memory and the stack for super low level programmer reasons I, kniw nothing about.
But it SHOULD work. In theory. It worked before.
On the other hand, a mutex seems SO cheap that it would out perform my crappy guard. It seems like I would gain very little my way. I don't know.