This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: dlopen and memory order guarantees with threads
On Sat, Mar 3, 2012 at 1:21 PM, edA-qa mort-ora-y <eda-qa@disemia.com> wrote:
> Great, that's very helpful. Essentially the loader relies on mmap to
> provide all visibility guarantees across the processors. Do you know if
> there is any doc/spec which makes this guarantee explicit (the man page
> and POSIX references don't appear to explicitly mention this aspect).
No, it's not that specific. The loader relies on mmap to provide all
visibility guarantees for all threads in a process. Nothing more.
There is no specification that makes the guarantee because doing so
would tie the specification to a strict set of requirements that might
contradict what is required to achieve optimal performance for a given
architecture or OS.
The only guarantee the standard makes is that the loader functions
are thread-safe.
> To ensure I tracked this correctly through the code, the actual call to
> __mmap is in the "_dl_map_object_from_fd" function in <elf/dl-load.c>.
> Is that correct (at least for ELF files)?
Yes. GLIBC only supports ELF.
> Somewhat unrelated, but if I read this correctly then, since the dl-open
> just mmaps the file, that means glibc is solely responsible for handling
> variables marked as thread-local (that is, not the OS).
Correct.
GLIBC handles all thread-local data, but may rely on the kernel
for help. Not all architectures are the same, so you can't assume anything
without looking at the code. Some architectures use the kernel to mediate
access to a special register which is used by the thread to handle
thread-local data.
Cheers,
Carlos.