Many accesses to the NodeList struct by the server will cause a very large overhead and bottleneck even for reads. Accessing the NodeList from a read after/during a lock for a write (insertion, deletion, etc) can also cause data races or use-after-free issues from removals, so contention is not just between writes, as we previously thought.
This overhead could be significant because every message received by the server requires, at the very least, a broadcast to all other nodes, meaning traversal and sending only actually happens for one message at a time.
We need to:
- Find a lighter alternative to a standard mutext to associate with the list (e.g. read/write lock)
- Abandon server concurrency
- Find another alternative
Concurrency is preferable but, currently, there is very little to gain from multiple threads.
Many accesses to the NodeList struct by the server will cause a very large overhead and bottleneck even for reads. Accessing the NodeList from a read after/during a lock for a write (insertion, deletion, etc) can also cause data races or use-after-free issues from removals, so contention is not just between writes, as we previously thought.
This overhead could be significant because every message received by the server requires, at the very least, a broadcast to all other nodes, meaning traversal and sending only actually happens for one message at a time.
We need to:
Concurrency is preferable but, currently, there is very little to gain from multiple threads.