This is the mail archive of the
mailing list for the GCC project.
Re: thoughts on libatomic
- From: Lawrence Crowl <crowl at google dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 23 Apr 2012 15:06:00 -0700
- Subject: Re: thoughts on libatomic
- References: <firstname.lastname@example.org> <4F95ADAE.email@example.com> <4F95C1CA.firstname.lastname@example.org>
On 4/23/12, Andrew MacLeod <email@example.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.