On 09/03/2016 01:30 PM, Kurt Roeckx wrote:
Hi, We're looking into moving a reference counter from a lock to atomics because the lock currently seems to be a bottleneck for some workloads. Some platforms don't seem to be proving lock free atomics, like armv5. My understanding is that if we use the atomics (C11 or gcc built in) that it would use an external function that might possible take a lock, or maybe do something else so that we get the atomic behaviour we want. Since we support platforms that don't have the atomics, we at least need to still support the locks we take ourself. Is there any benifit in taking a lock ourself when the atomics are not lock free? For instance we might have a lock per object instead of some global lock. But we'd probably need 2 kernel calls when we take the lock ourself while it might be possible that the atomics library can do it with only 1 system call, probably with the kernel's help.
If you're incrementing several counters, with your own locking you can increment them under a single lock, while using the atomics library might result in the lock being taken and released several times.
I'm also wondering why the library provides functions for checking that it's lock free. I guess it's to be able to make such a decision, but it's not obvious. Does someone have some guidance for what's the best to do? Maybe some information about how things are implemented?
