This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |