Do I Need -D_Reentrant with -Pthreads

Do I need -D_REENTRANT with -pthreads?

For me the best answer was the comment from pts if only he bothered to submit it as answer:

You investigated properly and answered
your own question. Use g++ -pthread,
it is equivalent to g++ -lpthread -D_REENTRANT.
Using g++ -D_REENTRANT would be different,
it may not set all the linker flags. –
pts May 18 at 0:30

Why do we write -D_REENTRANT while compiling C code using threads

You don't have to write it. But it is recommended.

Defining _REENTRANT causes the compiler to use thread safe (i.e. re-entrant) versions of several functions in the C library.

Significance of -pthread flag when compiling

Try:

gcc -dumpspecs | grep pthread

and look for anything that starts with %{pthread:.

On my computer, this causes files to be compiled with -D_REENTRANT, and linked with -lpthread. On other platforms, this could differ. Use -pthread for most portability.

Using _REENTRANT, on GNU libc, changes the way some libc headers work. As a specific example, it makes errno call a function returning a thread-local location.

gcc difference between -pthread and -pthreads?

The Solaris -pthreads and Linux -pthread options do equivalent things. Apparently, gcc-4.x series accepts -pthread for Solaris as well.

You do want the -pthread/-pthreads option while compiling because it adds multithreading support in the preprocessor and the linker.

No deadlock unless linked to pthreads?

The following will deadlock when linked with pthreads library and will not deadlock if pthreads is not linked in.

That's because the default implementation of std::mutex::lock does nothing.

is the compiler aware of the libraries that are linked in?

No: the compiler simply calls std::mutex::lock and passes it the address of mtx. It's the implementation of that function that behaves differently.

Update:

To clarify, the implementation is able to change itself depending on if a library has been linked in? Through a macro?

By the time the compiler is done compiling, macro preprocessing is also done and can not have any further effect.

Perhaps it's best to demonstrate. Suppose you have:

int main() { return foo(); }

Can you tell what the result of execution of above program is? No, you can't, because you don't know what foo does.

Suppose now that I compile the following:

// foo.c
int foo() { return 0; }

gcc -c foo.c && ar ruv libfoo.a foo.o
gcc main.o -L. -lfoo

Now you can tell that the program will exit with 0 return code.

Now suppose that I also compile the following:

// bar.c
int foo() { abort(); }

gcc -c bar.c && ar ruv libbar.a bar.o

Finally, I link the same unmodified main.o like so:

gcc main.o -L. -lbar -lfoo

Can you tell what the resulting program will do?

You can: it will die with SIGABRT and produce a core dump.

Notice that main.o did not change, only the libraries that main.o is being linked against have changed.

This is exactly the same mechanism that causes your original program to behave differently depending on whether or not it is linked against libpthread.

---

Related Topics