Re: Thread starvation and resource saturation in atomicity functions?

[Ian Lance Taylor <iant at google dot com>]

"Chad Attermann" <chad@broadmind.com> writes:

> Hello all.  Late last year I posted a couple of questions about
> multi-threaded application hangs in Solaris 10 for x86 platforms, and
> about thread-safety of std::basic_string in general.  This was an
> attempt to solve persistent problems I have been experiencing with my
> application hanging due to CPU utilization shooting to 100%, with the
> __gnu_cxx::__exchange_and_add function frequently making appearances
> at the top of the stack trace of several threads.
>
> I believe I have made a break-through recently and wanted to solicit
> the opinion of some experts on this.  I seem to have narrowed the
> problem down to running my application as root versus an unprivileged
> user, and further isolated the suspected cause to varying thread
> priorities in my application. I have theorized that spin-locks in gcc,
> particularly in the atomicity __gnu_cxx::__exchange_and_add function,
> are causing higher priority threads to consume all available cpu
> cycles while spinning indefinitely waiting for a lower priority thread
> that holds the lock.  Now I am already aware that messing with thread
> priorities is dangerous and often an excercise in futility, but I am
> surprised that something so elemental as an atomic test-and-set
> operation that may be used extensively throughout gcc could possibly
> be the culprit for all of the trouble I have been experiencing.

You explicitly mentioned x86.  For x86, __gnu_cxx::__exchange_and_add
does not use a spin-lock.

If you mean that other code may use spin locks built on top of
__exchange_and_add, then, yes, in that case you could be getting a
priority inversion.  But gcc itself does not use any such code.  So if
you are seeing a problem of this sort, it is not a problem with gcc.

Ian