This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: thoughts on libatomic


On 4/23/12, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 04/23/2012 03:29 PM, Richard Henderson wrote:
> > > - load_n.c:
> > >    - I'm concerned about the CAS on read-only mprotected pages?
> > >      Why again do we think this is safe?  Does the standard
> > >      explicitly allow this?  Or should we just use a lock in
> > >      this case?
> > Andrew, you had a bit of back-and-forth with someone about this.
> > Can you dig that up?
>
> yes, this keeps coming up again and again....  I think you should
> take it up with Lawrence Crowl... He was the one, (along with
> some input from Jeffrey Yasskin) that concluded that it was OK
> to use it, even if it was just sort of shoehorned in so that we
> could get 16 byte lock free on the most common architecture...

The earlier discussion was about volatile.  Given the way the C++
standard works, I think the volatile issue really only affects
programmers that want to access device registers with atomic
operations.  Machines are lots more complicated than they were when
I accessed device registers, so I don't have a good feel for what
the current expectations are.  The standard is somewhat vague on
volatile, so I think the CAS-based read is likely to be permitted.
Even so, I have brougt up the issue with the C++ standard folks,
and maybe we can get some more feedback here.

> it came down to something like the architecture manual entry
> for cmpxchg16 states that a store cycle may be added by the
> hardware under the covers, and as such, it is a part of the
> basic machine description, and therefore we might as well use
> the instruction even though we may be adding the store cycle
> ourselves sometimes....
>
> I haven't found the actual communication for reference yet,
> I'll look again tomorrow.

The standard says nothing about mprotect, so the implementation
gets to define all the semantics.  However, if the hardware gives
a fault for the CAS but the programmer specified a simple read,
the programmer may be a bit miffed.  Even so, I don't think we have
any other reasonable choice in the short term.  We will probably
need to wait for hardware to catch up.

-- 
Lawrence Crowl


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