This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Atomics and lock free




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?





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]