4 ms·
Interesting, but I'm still of the opinion that it's better to just avoid k-CAS in the first place. This is usually possible with sufficient control over your me
by o11c 3y ago
Interesting, but I'm still of the opinion that it's better to just avoid k-CAS in the first place. This is usually possible with sufficient control over your memory allocation/deallocation patterns.
(Also, I really hate spinlocks, since the scheduler can totally ruin them - with a good atomic algorithm, you can guarantee that if you have to loop, it is only because somebody is is actively making progress, with no possibility of them being unscheduled).
- amluto 3y agoWhere do you see k-CAS? If, by control of allocation you mean doing something like RCU or its garbage-collected equivalent, sure, if it’s reasonable in your environment, go for it. But seqlocks and their variants produce no garbage and can be extremely efficient in appropriate contexts. (The Linux vDSO, for example, cannot usefully participate in GC or RCU. seqlocks it is.)