CODEWITHSUNDEEP
multithreadingthread-safetypthreads
Brian Vandenberg
Brian Vandenberg

Reputation: 4121

Can -pthreads (gcc) or -mt (sun studio) or similar options cause problems?

I'm working on a build for an old project that wasn't maintained well at all; it's more or less a hodgepodge of hundreds of independent projects that get cobbled together. Naturally, that means there's a lot of inappropriate things going on.

There's probably 50-100 executables, and around 300 shared/static libraries. Some of the libraries are built with the -mt flag (sun studio; -pthreads appears to be the gcc equivalent), others aren't.

This seems potentially problematic to me. Suppose I have libA.so and libB.so -- A was built with -mt, but not B. I expect if the application linked against A & B is single-threaded there won't be any problems (feel free to correct me on that). However, if the app is threaded then this situation opens a fun can of worms.

I'm inclined to just build everything with -mt and have done with it. Most of the office agrees with this plan, but there's one dissenter. My expectation is that this will just create a potential degradation in performance, but at the moment performance is already abysmal because of the poor state of this project; so I'm not worried about that.

In short: are there any potential pitfalls with doing this?

Upvotes: 0

Views: 251

Answers (1)

Anton Kovalenko
Anton Kovalenko

Reputation: 21507

I would expect problems for libraries which are actively caring about being compiled with threads (#ifdef _REENTRANT is a sign of it). When some code has not been compiled for ages, and it suddenly becomes active, its problems might become visible. (It's even not so much about threading, just about any code which was ifdeffed out for a long time).

A special case of the above is a library which tries to use pthread_atfork in a manner which is described in RATIONALE section here: these things are far from well-defined, posixly speaking, because creating threads, releasing locks, etc. is not async-signal safe. Your platform may provide some guarantees about what actually happens (e.g. it might even specify whether atfork handlers are invoked for the fork happening in a signal handler). This thing should not matter if fork is not actually used, but otherwise it has a real chance to misbehave.

Summary: don't expect much problems from libraries that don't care about threading. Expect them from libraries that care and are (possibly, in some circumstances) doing it wrong.

Upvotes: 2

Related Questions