Re: smrproxy v2

On 11/24/24 19:47, Chris M. Thomasson wrote:

On 11/24/2024 4:09 PM, jseigh wrote:

...

 Actually, I remember way back where a scenario that had a lot of writes would start to mess with a deferred reclamation wrt a polling thread type of “scheme”. Too many deferred nodes would start to "pile up". Basically, the single polling thread was having trouble keeping up with all of them. The interlocked versions seemed to perform sort of "better" in a sense during periods that had a lot of frequent “writes”. Of course clever use of node caches helps heavy write periods. Anyway, some of the tests just used a mutex for writes, others used lock-free and would generate high loads of them that would push and pop nodes and defer them to the poll thread to test how much load it (poll thread) could take.

Using deferred reclamation to implement a lock-free queue will slow
things down.  Also cache line thrashing will limit how fast queue
operations will go no matter what.
Better to parallelize.  You can take a really bad lock-free queue
implementation, parallelize it, and then tell everyone how fast
your queue is.
Single queue at 1 op/sec.
Parallel queue on 1000000 processors, 1000000 op/sec.
Joe Seigh