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

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


On Thu, 2015-08-27 at 09:34 -0400, Carlos O'Donell wrote:
> 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.
> 
Ok you asked for it ...

The key words are Context Synchronizing and Execution Synchronizing.

PowerISA 2.07B Book I Power ISA User Instruction Set Architecture

2.7 System Call Instruction

states that sc is Context Synchronizing. ie the call to clone or futex

PowerISA 2.07B Book II Power ISA Virtual Environment Architecture

1.7.3 Atomic Update

Contains a Programming note on how and why reservations must be clears
on interrupts and context switches.

4.4.3 Memory Barrier Instructions

States that sync is execution Synchronizing

PowerISA 2.07B Book III-S Power ISA Operating Environment Architecture -
Server Environment [Category: Server]

1.5.1 Context Synchronization
1.5.2 Execution Synchronization

Give the architectural definition of the those terms

6.4.3 Interrupt Processing

Interrupts include System Call. This section contains a Programming Note
that states:

"In general, when an interrupt occurs, the following
instructions should be executed by the operating
system before dispatching a ânewâ program."

and provides a list of required actions including clearing any
reservations / transactions and executing a full (hwsync) sync memory
barrier.

QED a Clone syscall is effectively a full barrier (Sequentially
Consistent) between stores in the thread parent and loads in the thread
child.

You can inspect the kernels context switch code yourself ;)

> 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.
> 
> Cheers,
> Carlos.
> 



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