On 4/23/12, Andrew MacLeod <amacl...@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
