Is gcc and libgcc_s.a thread-safe ?

Is gcc and libgcc_s.a thread-safe ?

[biju64]

Hello anyone,

We have a project where we use the gcc compiler and the libgcc_s.a (Compiler
collection library) to build executables on AIX 5.3 (powerpc). Please note
that we don't use the GNU C Library but instead use the AIX's own libc.a for
the C functions.

We have a plan to use threads for some executables / some functions. Before
we do this I want to be sure that the code generated by gcc and the
libgcc_s.a are both thread-safe.

Can anyone point me to some GNU/GCC documentation (or have any experience)
regarding this ? Is is safe to assume that both the code generated by gcc
and the libgcc_s.a libraries are thread-safe ?

Please help,
Grateful for any pointers.

Regards
Alex
-- 
View this message in context: http://www.nabble.com/Is-gcc-and-libgcc_s.a-thread-safe---tp21542269p21542269.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Is gcc and libgcc_s.a thread-safe ?

[John (Eljay) Love-Jensen]

Hi Alex,

> Can anyone point me to some GNU/GCC documentation (or have any experience)
regarding this ? Is is safe to assume that both the code generated by gcc and
the libgcc_s.a libraries are thread-safe ?

You¹ve sort of asked a loaded question.

GCC is as thread-safe as the programmers who use threading in their C code,
make their code thread-safe.

GCC supports some thread-safe idioms, such as making sure that static
variables are thread-safe initialized, but there is a caveat race condition
for a series of static variables that may cause a surprise.

Ultimately, the thread-safe issues for GCC are not GCC problems, rather they
are C problems.

Some C library routines are *NOT* thread-safe, often because they are not
re-entrant.

C is not a thread-safe language.  If you read the C specification (ISO
9899), you will find that on the issue of threading facilities, the
specification is silent.

All threading solutions for C are add-on libraries, and as such to use to
threading facilities you (the developer) need to abide by that threading
system¹s constraints, conventions and disciplines.  By ³disciplines², that
means that the developers who use those threading facilities must be
meticulous to adhere to those threading constraints.  Violation of those
constraints will mean a threading-related bug in your code*.

C++ runs into the same morass of threading problems.  There are some nice
platform neutral threading abstractions in C++, such as provided by Boost or
RogueWave, but ultimately C++ (ISO 14882) does not provide a threading
solution as part of the specification.

There are languages that have strong threading guarantees, because threading
is built into the specification.  Languages such as Ada, Java, Haskell, D
programming language, or Erlang.

Detractors of threading in those languages will point out that their
solutions have shortcomings or inefficiencies (especially on some platforms
moreso than others).

A threading library solution, such as used in C and C++, give flexibility,
at the expense of portability (using the OS¹s threading facilities
directly), or require using a platform neutral abstraction (such as Boost or
RogueWave).  And, as mentioned, demand a very high rigor of meticulousness
regardless if using native threading facilities or a threading abstraction.

Sincerely,
<Eljay

* In C, threading bugs are far too often very hard to debug.  Does not
matter if it is GCC or some other compiler.

Re: Is gcc and libgcc_s.a thread-safe ?

[biju64]

Thanks Eljay for that prompt reply.

So as I understand GCC itself is 'thread-safe' but it depends primarily on
the underlying C code that is implemented. ie. if the C code is thread-safe
then the overall exe generated is thread-safe. Got it.

What about the libgcc_s.a library that we have to link in if using gcc ? Do
I need to worry about this ?
On google I see something called libgcc_s_pthread.a - What does this do ? Do
I need this ? 

Have anyone seen any gcc documentation regarding this library ?

Regards,
Alex

-- 
View this message in context: http://www.nabble.com/Is-gcc-and-libgcc_s.a-thread-safe---tp21542269p21544584.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Is gcc and libgcc_s.a thread-safe ?

[Ian Lance Taylor]

biju64 <alex.jacob@logica.com> writes:

> What about the libgcc_s.a library that we have to link in if using gcc ? Do
> I need to worry about this ?
> On google I see something called libgcc_s_pthread.a - What does this do ? Do
> I need this ? 

gcc's supporting libraries are all thread-safe.

I don't know what libgcc_s_pthread.a is--it's not part of a regular
gcc distribution.

Ian

Re: Is gcc and libgcc_s.a thread-safe ?

[biju64]

Thanks Ian for the prompt reply.
Regards,
Alex


Ian Lance Taylor-3 wrote:
> 
> biju64 <alex.jacob@logica.com> writes:
> 
>> What about the libgcc_s.a library that we have to link in if using gcc ?
>> Do
>> I need to worry about this ?
>> On google I see something called libgcc_s_pthread.a - What does this do ?
>> Do
>> I need this ? 
> 
> gcc's supporting libraries are all thread-safe.
> 
> I don't know what libgcc_s_pthread.a is--it's not part of a regular
> gcc distribution.
> 
> Ian
> 
> 

-- 
View this message in context: http://www.nabble.com/Is-gcc-and-libgcc_s.a-thread-safe---tp21542269p21581190.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Is gcc and libgcc_s.a thread-safe ?

[Michael Haubenwallner]

On Mon, 2009-01-19 at 17:08 -0800, Ian Lance Taylor wrote:
> biju64 <alex.jacob@logica.com> writes:
> 
> > What about the libgcc_s.a library that we have to link in if using gcc ? Do
> > I need to worry about this ?
> > On google I see something called libgcc_s_pthread.a - What does this do ? Do
> > I need this ? 
> 
> gcc's supporting libraries are all thread-safe.
> 
> I don't know what libgcc_s_pthread.a is--it's not part of a regular
> gcc distribution.

Err - it is not part of a _recent_ (>= gcc-4) on *AIX* any more, but up
to gcc-3.4, these libgcc_s* were provided by gcc on AIX:

$ cd /prefix/of/gcc-3.x
$ find . -name 'libgcc_s*
./lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/libgcc_s.a
./lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/libgcc_s_pthread.a
./lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/libgcc_s_ppc64.a
./lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/libgcc_s_pthread_ppc64.a

and theses were the libstdc++* ones:
$ find . -name '*.la' -prune -o -name 'libstdc++*' -print
./lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/pthread/ppc64/libstdc++.a
./lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/pthread/libstdc++.a
./lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/ppc64/libstdc++.a
./lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/libstdc++.a

Note: These are the _shared_ libraries on AIX.

I've always tried hard to _not_ have pthread- and non-pthread-variants
of both libgcc_s (distinguished by filename) and libstdc++
(distinguished by path) as runtime dependencies of my shared libraries
and executables.

In the end, I patched the gcc source (specs) to always behave as if
'-pthread' was passed on the commandline, but it also should work to
have a wrapper-script that always passes '-pthread'.

Even if I did not necessarily use pthreads in my application, I could
not be sure that each required library was built without -pthread. So I
built each library where I have sourcecode for using that patched gcc.
Having pthreads enabled always does not really hurt, even when not used.

Since gcc-4.1 (haven't tried gcc-4.0), the pthread-specific libs are
gone, but I still patch gcc-source to enable pthreads always. I'm not
sure if it is really necessary any more, but it still works.

HTH,
/haubi/