This is the mail archive of the 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]

Re: [PATCHv2] powerpc: ABI change - add HWCAP/HWCAP2/platform info to TCB

On 08/26/2015 10:49 PM, Steven Munroe wrote:
> I really should not work after 9:00PM ... :(
>> I think the comments and documentation should be explicit with the
>> following assumptions.
>> The initialization of the static variables __tcb_hwcap, __tcb_platform
>> and __tcb_hwcap_init must occur before main() gets control and before
>> any other threads can exist.
> Before Library init/ctors and main() get control for the main thread.

That sounds like a good design goal. In which case you also have to do
this before auditing libraries are initialized. Therefore it has to happen
very early, earlier than TLS_INIT_TP for the main thread, so you may need
to do it in dl_platform_init(), though you'll have to check.

The code comments should make these assumptions clear e.g. early init.

>> The TCB fields hwcap and at_platform must be initialized from the
>> corresponding static variables before: Library init/ctors get control
>> for the main thread, and before any new thread gets control from clone.
> before: Library init/ctors and main() get control for the main thread,
> and before any new thread gets control from clone.
That also sounds good. You'll likely need to do this in the nptl code
that starts the thread e.g. createthread.c via TLS_DEFINE_INIT_TP.
>> As these are aligned words/dwords the stores are effective atomic
>> relaxed MO in the PowerISA. In addition the stores to the static
>> variables (__tcb_hwcap, __tcb_platform) occur while only one thread
>> exists and the kernel will enforce sequential consistency before the
>> child of the clone syscall can execute any load from static variable
>> __tcb_hwcap, or __tcb_platform. As to copy (load of __tcb_hwcap,
>> __tcb_platform and store or TCB fields hwcap and at_platform) always
>> occurs within a single thread and copies to thread local storage, there
>> is no data race.
>> Does this help?
> Hopefully this helps even more.

It does help, and your answer makes perfect sense.

One question though, could you share the source of that guarantee that
clone enforces a synchronized-with (SW) between the child and parent thread?
If we don't assume SW I think there are probably more broken things that
need fixing, so it must be true. I'm just curious if you had any real
guarantees given to you that would backup what we all assume must be true.

Note that the term "sequantial consistency" isn't really what I think we
want to talk about in this case since that's not something I would use
to explain a synchronization between two threads (child and parent).
Rather it is a condition applied over an execution and we certainly don't
want that condition applied generally to both threads.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]