Atomics and lock free

Avi Kivity avi@scylladb.com
Sun Sep 4 12:22:00 GMT 2016



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?
>
>
>



More information about the Gcc-help mailing list