Can each thread in a process open up different dynamic libraries to resolve
the same symbolic name?
In my reading of the dlopen, dlsym functions, I don’t see why not, but I
thought I’d ask before I spend to much time to find out that you can’t.
Background of problem for those interested:
I have multiple threads running in a single process. Each thread implements
a ‘servo axis process’. The servo axis process at a very high level is
basically the following:
main() {
position=getposition();
output=process_data(position);
motoroutput(out);
}
The problem is that axis thread 1 may need to get it’s position from one
piece of hardware, while axis 2 needs to get it’s position from another
piece of hardware, and this hardware may change. We would of course like to
not have to recompile. We were planning on handling this with resource
manager(s) as follows and a configuration file that tells each axis thread
what resource manager (hardware device) and channel to get it’s position
from. Show below:
[axis1]
posdev="/dev/posdev.ddc/1" ; this means channel 1 of the DDC
implementation of a Position Device
[axis2]
posdev="/dev/posdev.ddc/2" ; save device as above but channel 2
(posdev.ddc takes care of channel mapping)
[axis3]
posdev="/dev/posdev.nai/1" ; channel 1 of the NAI implementation of a
position device
Therefore, when each axis thread starts, the config file tells it which
device ( or resource manager) and channel to open to get it’s position
information from.
We’re doing this now with resource managers for specific versions of
hardware that implement the DEVCTL messages defined for all position
devices. That way I simple point an axis thread to a different resource
manager if the hardware changes In concept this seems to be working very
well for us. However, the resource managers are taking way too long (see
below postings).
We thought that a static or shared library might work well and it would
eliminate the out of process call to a resource manager. However, since all
axis threads are in the same process, we can’t link each thread against
different implementations of a library.
So my question now is: Is it possible for each axis thread to load a
different dynamic library to resolve the function calls to ‘GetPosition’? In
my reading of the dlopen, dlsym functions, I don’t see why not.
Chris Rose wrote:
Therefore, when each axis thread starts, the config file tells it which
device ( or resource manager) and channel to open to get it’s position
information from.
We’re doing this now with resource managers for specific versions of
hardware that implement the DEVCTL messages defined for all position
devices. That way I simple point an axis thread to a different resource
manager if the hardware changes In concept this seems to be working very
well for us. However, the resource managers are taking way too long (see
below postings).
What is the sample rate necessary for your control loop (if you don’t
mind me asking) ?
We thought that a static or shared library might work well and it would
eliminate the out of process call to a resource manager. However, since all
axis threads are in the same process, we can’t link each thread against
different implementations of a library.
So my question now is: Is it possible for each axis thread to load a
different dynamic library to resolve the function calls to ‘GetPosition’? In
my reading of the dlopen, dlsym functions, I don’t see why not.
AFAIK no. Memory mappings are per process, not per thread. If you don’t
require your application to be network distributable, you could modify
your resource manager so that the devctl’s are used to get a handle into
a shared memory area that the resource manager writes directly into, and
your client process reads directly from (using mutex’s for sync). As
long as the data format stored in the shared memory is consistent
between hardware types (no different in principle than a common message
format for a devctl) then you gain the hardware independence without
context switches (as I mentioned before, what you lose is network
transparency - i.e. the ability for your control algoritm client and
your driver to reside on different nodes on the network).
Rennie
Chris Rose <esorcc@hotmail.com> wrote:
Can each thread in a process open up different dynamic libraries to resolve
the same symbolic name?
Sure.
The problem is that axis thread 1 may need to get it’s position from one
piece of hardware, while axis 2 needs to get it’s position from another
piece of hardware, and this hardware may change.
Hm…kind of like io-net dealing with different network cards.
We thought that a static or shared library might work well and it would
eliminate the out of process call to a resource manager. However, since all
axis threads are in the same process, we can’t link each thread against
different implementations of a library.
So my question now is: Is it possible for each axis thread to load a
different dynamic library to resolve the function calls to ‘GetPosition’? In
my reading of the dlopen, dlsym functions, I don’t see why not.
Should work. You’ll have to be careful to make sure you don’t make a
mistake about common data functions going to the wrong hardware or something
like that – but will work fine. Also, there will be nothing to prevent
thread1 from using thread2’s library – other than that it shouldn’t
know about it – but that is normal. That is, the two resolutions of the
same symbol aren’t protected on a per-thread basis, but if only one thread
has a reference to the symbol, only that one will be able to use it.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Should work. You’ll have to be careful to make sure you don’t make a
mistake about common data functions going to the wrong hardware or something
like that – but will work fine. Also, there will be nothing to prevent
thread1 from using thread2’s library – other than that it shouldn’t
know about it – but that is normal. That is, the two resolutions of the
same symbol aren’t protected on a per-thread basis, but if only one thread
has a reference to the symbol, only that one will be able to use it.
My bad. I misread the original question. Yes this would work, of course;
and is in fact the correct approach, (it’s what dll’s are for). There might
be a few run-time linking gotchas depending on how the current (1 resmgr
per hardware type) code is structured. In the future, I’ll try to refrain
from answering questions when working late on Friday night 
Rennie