Shared library confusion


I’m a little bit confused abut the behaviour of shared librarys. On non-QNX-systems I noticed following behaviour:

When two applications A and B use the same shared library and A sets parameter to that library that are stored in global variables, application B is able to access these values (by using an appropriate read function). Means global variables within shared libraries are global to all processes that use that shared library; processes can exchange data using this way.

Now I tried the same on QNX: here the global variable is not global to all processes, it seems that every provess gets its own data segment.

So now my question is: is that a special QNX feature or did I miss something important when creating these other shared libraries on Linux?

It seems very dirty approach to use lib globals to exchange data. Why not use Message Passing, Queues, Signals or even Shared Memory?

I’ve never tried to use global vars in a shared lib under Neutrino - usually when writing libs you explicitly want every user of the lib work with its own data to have thread safety. QNX usually is using TLS (Thread Local Storage) for that.

Ahem…it was not the intention to use these variables for communication, it was an unwanted side effect (I used that only to describe what happened).

Yes, that’s exactly the behaviour I’d expect…

So that is something QNX-specific?

OK, after some further investigation I got the point: There is a big difference wether a shared library is loaded/linked during application startup (there TLS mainly works) or if it is accessed dynamically during runtime (there TLS fails - at least for non QNX-systems).

Your requirements are very confusing. You describe how to use global variables to communicate between processes but mention that QNX doesn’t do this. Then you state that you are not interested in in communicating this way. Maybe you need to describe what you are trying to accomplish?

The global variables of shared objects are independent for each instance of that object linked. This is because when you link a shared object, the proccess maps the same physical location for the code but unique locations for the data section. You can reda more here: … emory.html

And this is definitely the spected behavior for so.