Sent from my iPhone
On Dec 5, 2012, at 16:31, "Patrick J. LoPresti" <[email protected]> wrote: > On Wed, Dec 5, 2012 at 10:29 AM, Leif Walsh <[email protected]> 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(); >> } > > I am going to repeat myself a bit because this is an important point. > Then I will give up. > > First, this code smells on its surface. If I were interviewing a > candidate who submitted this as a code sample, it would be an easy > "strong no hire" decision. Ouch. > Grabbing a reader lock to write a > variable? What the heck is that? It's an eviction heuristic. It doesn't even need to be perfectly accurate. > > No matter how smart you think you are, sooner or later, you will work > with people who lack your genius. Truly smart programmers write code > that any idiot can prove correct. This does not qualify, to put it > mildly. > > Second, as we keep trying to explain, concurrent writes to the same > location are *undefined behavior* under every common threading model > (including, in particular, POSIX and C++11). That means a compiler > looking at this code can PROVE that only one thread ever runs the > first block concurrently. If that is not true, then you have > introduced a contradiction into the compiler's reasoning. "From a > contradiction, anything follows." How badly this code breaks depends > only on how smart your compiler is, and they get smarter all the time. Try to sell a compiler that generates a random executable just because it proves undefined behavior. I'm not trying to be (that) snarky, just realistic. I understand the risk you're describing and I appreciate you taking the time to do so. But adding extra fences here just because some theoretical compiler might turn this code into a giraffe drawing program is not a useful way for me or the CPU running my program to spend our time. > >> Boehm's paper did not convince me of a bug. > > When dealing with multi-threading, the right question is not "Do I > fail to see the problem?" The right question is "Can I create a > simple proof that there is no problem?" > > In my experience, most programmers either get this right away, or they > never will. > >> Since pthread locks will include proper mfences I believe this to be correct >> even on non-x86 machines. > > (a) You believe incorrectly, because undefined behavior can result in > anything whatsoever. > > (b) Even if you were correct, the chain of reasoning to prove it is > too long for maintainable code. > > Anyway, Helgrind is perfectly correct to warn about this bug. It is. > > - Pat ------------------------------------------------------------------------------ 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
