Sujet : Re: smrproxy v2
De : chris.m.thomasson.1 (at) *nospam* gmail.com (Chris M. Thomasson)
Groupes : comp.lang.c++Date : 25. Nov 2024, 23:12:37
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vi2sol$31jrd$1@dont-email.me>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
On 11/25/2024 3:31 AM, jseigh wrote:
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.
LOL! Yeah. In layers. Per thread queues, per cpu queues and some hashed global ones. Then we get to play with single consumer/producer, multi consumer single producer, and all that jazz... ;^)
Actually it was a RCU algorithm wrt deferred reclamation that worked great with read mostly. Then exposing it to a lot of writes sort of messed around with it, in a bad way. ;^)
The writes were able to swamp things under heavy artificial load.
Single queue at 1 op/sec.
Parallel queue on 1000000 processors, 1000000 op/sec.