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: Is gcc and libgcc_s.a thread-safe ?


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.


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