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 4:16 PM, edA-qa mort-ora-y <eda-qa@disemia.com> wrote:
> On 03/03/2012 08:28 PM, Carlos O'Donell wrote:
>> 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.
>
> Okay, so that does mean there could be (at least theoretically) OS's
> and/or hardware where dlopen/dlsym could actually provide a pointer to
> an address not visible, or not current, on another processor? Is there
> such a system?
Theoretically? Sure.
Is there such a system? No.
If there was it would be broken.
However, the standard says nothing about it really.
> But surely then the kernel docs would make mention of this, wouldn't
> they? Say for example Linux must state somewhere precisely mmap handles,
> or is it more of an information expected guarantee at this point
> (considering how hard it'd be to use dlopen safely otherwise)?
A well-documented commercial kernel may include this information
in their documentation to help users write correct userspace code.
In general coherency it is an expected guarantee that userspace
has from the kernel and the underlying hardware.
The kernel has a tougher time though, it needs to manage coherency
between multiple processors.
> Sorry that I may be sounding quite picky about details. I've been doing
> a lot of low-level concurrent programming lately and am always trying to
> ensure I'm doing it absolutely correctly. There's a lot of incomplete
> details in this area it seems -- probably because exactly what is
> required is not 100% certain, and because it seems there is still a
> disagreement on division of work between hardware and OS.
No offense taken :-)
Cheers,
Carlos.