Messages in this thread | | | Date | Mon, 4 Nov 2013 10:07:44 +0100 | From | Peter Zijlstra <> | Subject | Re: perf events ring buffer memory barrier on powerpc |
| |
On Sat, Nov 02, 2013 at 08:20:48AM -0700, Paul E. McKenney wrote: > On Fri, Nov 01, 2013 at 11:30:17AM +0100, Peter Zijlstra wrote: > > Furthermore there's a gazillion parallel userspace programs. > > Most of which have very unaggressive concurrency designs.
pthread_mutex_t A, B;
char data_A[x]; int counter_B = 1;
void funA(void) { pthread_mutex_lock(&A); memset(data_A, 0, sizeof(data_A)); pthread_mutex_unlock(&A); }
void funB(void) { pthread_mutex_lock(&B); counter_B++; pthread_mutex_unlock(&B); }
void funC(void) { pthread_mutex_lock(&B) printf("%d\n", counter_B); pthread_mutex_unlock(&B); }
Then run: funA, funB, funC concurrently, and end with a funC.
Then explain to userman than his unaggressive program can return: 0 1
Because the memset() thought it might be a cute idea to overwrite counter_B and fix it up 'later'. Which if I understood you right is valid in C/C++ :-(
Not that any actual memset implementation exhibiting this trait wouldn't be shot on the spot.
> > > 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. > > #define __rcu __atomic
Yeah, except we don't use __rcu all that consistently; in fact I don't know if I ever added it.
| |