Sent from my iPhone
On Dec 5, 2012, at 15:38, Julian Seward <[email protected]> wrote: > On Wednesday, December 05, 2012, Leif Walsh wrote: >> Here are the threads I have: >> >> { >> pthread_rwlock_rdlock(); >> x = 1; >> pthread_rwlock_rdunlock(); >> } >> >> { >> pthread_rwlock_wrlock(); >> if (x) { >> x = 0; >> } else { >> foo(); >> } >> pthread_rwlock_wrunlock(); >> } >> >> Boehm's paper did not convince me of a bug. >> >> Since pthread locks will include proper mfences I believe this to be >> correct even on non-x86 machines. > > Well, but what's your definition of "correct"? That's central to the > issue at hand. > > Imagine that pthread_rwlock_rdunlock contains a one-sided fence, > that causes all writes done by other processors to be visible on > this processor, but has no effect on migrating writes done by this > processor to others. (Why should it? Holding a reader lock doesn't > allow you to write shared memory, so a conforming program should > have no writes that need to be propagated to other processors at > lock release time.) The important synchronization point isn't the rdunlock, it's the wrlock. I have a hard time believing that you can take a pthread write lock and then look at a value some other processor wrote before you took the lock and not get that value. That sounds like pthread is broken or I am being exceedingly thick. But everything I have read on this since I started asking around says that my code is fine. I agree that races that seem benign can easily stop being benign. I just don't think this is a race according to the spec. > > The above is just a guess. I'm not saying your code will fail on current > implementations. Merely that (as Patrick points out), non-adherence > to the standard puts the program pretty much in the Russian Roulette > department w.r.t. future hardware and compiler developments. > > You may remember the gcc -fstrict-aliasing wars of the early 2000s, > in which the gcc developers starting using a relatively obscure aspect > of the C/C++ standard to improve optimisation. As a result vast reams > of previously-working code (including Valgrind) started to fail in > obscure ways. > > Same thing happened on a smaller scale a couple of years later when > gcc started to assume that signed integer arithmetic would never overflow. > > So .. seen from a historical context, the compiler crews are an extremely > ingenious bunch, and I would not be at all surprised to see newer compilers > causing non-compliant (racey) code to fail more often. > > J ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
