Messages in this thread | | | Date | Fri, 1 Nov 2013 11:30:17 +0100 | From | Peter Zijlstra <> | Subject | Re: perf events ring buffer memory barrier on powerpc |
| |
On Fri, Nov 01, 2013 at 02:28:14AM -0700, Paul E. McKenney wrote: > > This is a completely untenable position. > > Indeed it is! > > C/C++ never was intended to be used for parallel programming,
And yet pretty much all kernels ever written for SMP systems are written in it; what drugs are those people smoking?
Furthermore there's a gazillion parallel userspace programs.
> and this is > but one of the problems that can arise when we nevertheless use it for > parallel programming. As compilers get smarter (for some definition of > "smarter") and as more systems have special-purpose hardware (such as > vector units) that are visible to the compiler, we can expect more of > this kind of trouble. > > This was one of many reasons that I decided to help with the C/C++11 > effort, whatever anyone might think about the results.
Well, I applaud your efforts, but given the results I think the C/C++ people are all completely insane.
> > How do the C/C++ people propose to deal with this? > > By marking "ptr" as atomic, thus telling the compiler not to mess with it. > And thus requiring that all accesses to it be decorated, which in the > case of RCU could be buried in the RCU accessors.
This seems contradictory; marking it atomic would look like:
struct foo { unsigned long value; __atomic void *ptr; unsigned long value1; };
Clearly we cannot hide this definition in accessors, because then accesses to value* won't see the annotation.
That said; mandating we mark all 'shared' data with __atomic is completely untenable and is not backwards compatible.
To be safe we must assume all data shared unless indicated otherwise.
| |