[text-only] On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump <mikest...@comcast.net> wrote: > On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov <dvyu...@google.com> wrote: >> I can't really make my mind on this. I would mildly prefer sleep's (if >> they work reliably!). > > Let me state it more forcefully. You don't have to convince us here. I'd love to get rid of sleep calls in the tsan test suite -- they are a minor but a constant annoyance. But I also want to keep the tests *very simple*, i.e. 1. Single file w/o any non-system includes, no linking of extra libraries/objects 2. Not too much extra code. (ideally, 1 line for init, 1 line for "signal", 1 line for "wait") 3. Strictly posix or c++11 (unless we are testing something specific)
Your idea with barrier_wait/dlsym sounds interesting, but I can't see the code in this mail thread. What do I miss? > sleeps are not now, nor in the history of computing ever been a > synchronization primitive, except for hard real time systems. If they were, > you would be able to cite a paper that uses them. If I am wrong, I’d welcome > a cite. Any failure of sleep to work is a indication that that system is not > a real time system, and the entirety of the gcc test suite is non-real time > code (unless someone snuck some in while I wasn’t watching). Only a > synchronization primitive can make the test cases deterministic, therefore, > sleep can never be used as a syntonization primitive in the gcc test suite. > >> Kostya, you had experience with both approaches. What are you thoughts on >> this? >> StealthNotification definitely makes tests faster and more reliable. Yep. > > To me, reliability isn’t a continuum for the gcc test suite. It is binary. > It is, or, is not reliable and deterministic. The standard for the gcc test > suite is to be realible and deterministic. > >> can't really come up with any objective downsides. he downside is more code in tests. If we can satisfy my definition of *very simple* (above) -- let's do it. >> not to mention that they waste testing time. We discussed this. With a parallel test runner this is not a problem. I don't say the sleeps are good, I just say that testing time is not an argument against them. Flakiness is. --kcc > > Nor I.
