>I didn't find any other measurements on the internet, please point me to them if you find them. It has been years since I have written thousands sockets serve

>I didn't find any other measurements on the internet, please point me to them if you find them. It has been years since I have written thousands sockets servers (used in forex), yet even a couple milliseconds per write would have made the entire operation useless. >another explanation could be false sharing effects that I didn't know well at the time. False sharing sucks, of course, but milliseconds seems way way too much again penalty. You'd need all cores updating the same cache line, even then I doubt it'd be that bad. Could it be the virtualization layer? (again I have run 'that' on bare metal only) >I think it should be possible to do some similar stuff with multiple readers and/or writers Multiple writes should be avoided entirely, contention on writing is what prevents scaling - false sharing is pretty much that. A writer honoring the readers is pretty simple - each reader has its own pointer and the write should fail (or spin) when the buffer is full. I think that's quite a classic structure and indeed - it requires no extra memory to communicate/hand-off. About latency - this is java's current GC that does still has a compaction phase. https://malloc.se/blog/zgc-jdk16 https://malloc.se/blog/zgc-jdk16