dlopen and memory order guarantees with threads

edA-qa mort-ora-y eda-qa@disemia.com
Sat Mar 3 06:14:00 GMT 2012


I call dlopen, then I call dlsym to get the address of some object, lets
say a C-string literal. Is this pointer immediately safe to use in
another thread of the same application (with respect to memory
ordering/visibility)?

My assumption is yes, but I don't see this as an explicit guarantee. If
I were to allocate memory on my own, and write a string to it, I would
need to have both threads issue a synchronization command (atomic memory
order, mutex, fence, etc.) in order for the other thread to safely use
the pointer to the string.*

How does dlopen, assuming it does, guarantee that any pointer returned
from dlsym points only to memory which is completely visible with
current data from any thread running on any processor?

Is this synchronization provided by glibc or by the underling OS (in
which case I'd be happy with a Linux explanation here). I tried
following the glibc source code, but I don't quite understand what
happens yet (what does GLRO(dl_open) call?)

(*Let's assume an architecture were memory ordering/visibility could
actually cause a problem, since on x86 we should be fine with my example
even without syncing. Of course also assume multiple processors with the
threads truly running concurrently.)

-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-help/attachments/20120303/a9a7f5a4/attachment.sig>


More information about the Libc-help mailing list