Atomics and lock free
Sun Sep 4 12:22:00 GMT 2016
On 09/03/2016 01:30 PM, Kurt Roeckx wrote:
> 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?
More information about the Gcc-help