Thread safe atomic operations in libstdc++ on ARM

[Jeff Gray <jeffg at magellan-technology dot com>]

Hello to everyone on the list,

I've got a problem with a toolkit built using crosstool 0.43 for ARM. My
development system is a PC running a current Ubuntu Linux.

The problem is that libstdc++ atomic operations, specifically
__exchange_and_add(), are not being built in a thread safe manner for
this CPU. This results in the C++ string library having serious problems
as it depends upon this function for reference counting.

My understanding is that for most CPUs, there is an assembly
implementation of this function in
/gcc/libstdc++-v3/config/cpu/<cpuname>/atomicity.h. But for ARM, there
is no assembly implementation, so it falls back to
/gcc/libstdc++-v3/config/cpu/generic/atomicity.h. This implementation
uses __gthread_mutex calls to provide thread safety.

This is a good system & I have no problem with any of this. Though I am
curious why there is an ARM assembly version of this function for the C
library in /glibc/sysdeps/arm/atomicity.h, but not in C++. I assume
there is some complication that prevents it being used in libstdc++.

The problem I have observed is that during build time, gthr.h is
deciding to include gthr-single.h, so atomicity.o does not contain any
references to __gthread_mutex functions. I just used a file viewer to
look for information in the object file, and also used objdump to look
for symbol references.

Looking through the build log, it doesn't look like this should be
happening at all. During the configure of libstdc++-v3, it reports:
configure: CPU config directory is cpu/generic
checking for thread model used by GCC... posix
configure: WARNING: No native atomic operations are provided for this
platform.
configure: WARNING: They will be faked using a mutex.
(I can supply more of this, but you should be able to reproduce this easily)

I have tested this problem by creating a multiple thread application,
where each thread did this:

_Atomic_word m_oAtomic = 0; // global variable

ThreadFunction()
{
  for (int i = 0; i < 50000; i++)
  {
     __exchange_and_add( &m_oAtomic, 1 );
     __exchange_and_add( &m_oAtomic, -1 );
  }
}

My full test uses the ACE library for threading, so I just cut out this
piece to illustrate what it's doing. When compiled & run on x86, the
value of m_oAtomic is always zero, indicating success, but on ARM it
shows various offsets as a result of no thread protection. If I change
this application to have explicit calls to mutexes around the inner
loop, then it runs perfectly (though much much slower than the original
version, which is to be expected).

I compile the application with the -pthread switch, which should enable
the threaded version of the standard library. As I understand it, in a
single threaded application, the weak references to __gthread_mutex
functions will result in nothing happening, where in multi-threaded
applications, the "real" mutex functions are called.

I know that it is good practice to use mutexes at an application level
to handle potential thread issues. But this issue was found through use
of shallow copies of string objects (such as passing by value). The
atomic functions are supposed to internally protect against multi thread
problems, but if they're not doing so, then problems result.

My crosstool setup is a custom one, but I was able to reproduce this
using the default 0.43 installation by running the demo-arm9tdmi.sh
script in its default state:
eval `cat arm9tdmi.dat gcc-4.1.0-glibc-2.3.2-tls.dat` sh all.sh --notest
I did not alter any crosstool files. I have also shown this problem
using gcc-3.4.4-glibc-2.3.5.

I did another test in my custom setup to force the use of gthr-posix.h
to be included. In arm9tdmi.dat, I changed this line:
GCC_EXTRA_CONFIG="--with-cpu=arm9tdmi --enable-cxx-flags=-mcpu=arm9tdmi
--enable-cxx-flags=-D_GLIBCXX__PTHREADS"

I know it's brute force to define the _GLIBCXX__PTHREADS & I didn't
expect it to create a workable library. Naturally, it didn't and got
very upset during linking of libstdc++. But I did manage to prove that
when I did this, that gthr-posix.h was called, and the resulting
atomicity.o object file did include calls to __gthread_mutex functions.

This is not the solution, just a test - but I don't understand whether
the weak reference versions of the mutex functions should show up or not
in the default build. But the fact that it is including gthr-single
makes me think it isn't.

Am I taking the wrong approach here? I have spent days searching
documentation and forums, but have been unable to see a solution. The
fact that I'm not finding other people reporting the same thing makes me
think there is some simple error I have made, but I cannot see it.

Jeff


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

--
For unsubscribe information see http://sourceware.org/lists.html#faq