On Tuesday 01 August 2006 15:32, Philip Guenther wrote: > On 7/31/06, David Leung <[EMAIL PROTECTED]> wrote:
> Yeah, that's not an uncommon result of code that doesn't meet the > synchronization requirements of pthreads. It was a piece of code given to us as a part of our OS class assignment. I guess the lecturer was under a bit of time pressure to get the assignment out, and didn't pay too much attention to the synchronization problem. I am still a bit surprised to see that it worked at all with optimization turned on (this is the first time I've ever worked with Pthread). I'm still trying to figure out why though. > Right, so the code caused undefined behavior and the compiler happened > to do the desired thing only when optimization was on. Did you not > see that same effect with other compilers on that code? > Did you not see that same effect with other compilers on that code? I haven't had the chance to yet, but I'm going to run it through Intel's compiler just to see if I can observe the same effect. Coming to think of it, even a total 'correct' compiler, if there is such a thing, shouldn't be expected to behave correctly when an undefined condition occurs. > What are you testing for? Correct operation of the resulting binary > or correctness of the code itself? Both, actually. When I got the piece of code, I have made the (bad) assumption that it works, and I didn't question the requirement on the assignment sheet to use -O2 optimization. This really has taught me a lesson they probably don't teach at the university :-) > Note that other cases of undefined behavior (say, violation of C's > aliasing rules) are likely to behave 'correctly' when optimization is > off. Thanks for the tip. Will keep that in mind.
