On 28 October 2007 18:03, Tomash Brechko wrote: > You got my intent all wrong. Performance matters for both sides. And > currently the only option for multithreaded programs is to use > volatile, which _greatly_ hurts performance. > > What I was trying to say, is that it would be nice to have > -fno-thread-unsafe-optimization option. And I was trying to say that > when you _enable_ this option, the performance won't be hurt much, > while the program will become thread-safe.
Thing is, if you disable all optimisations that are potentially unsafe in the presence of threads, won't you just get the same effect as if you had used volatile anyway, only on every single variable in the program instead of just the ones the programmer has designated as sensitive? > I never even said that > this option should be the default (though it would be reasonable for > -pthread or -fopenmp). Well, as I said before, I'm not going to complain about some optional flag that limits the compiler's optimisations, but I think that what's going to happen is that you're going to find another race condition caused by another optimiser, and want to add disabling that optimisation as well to this new flag, and there's going to be a long process of repeated cycles of this, until what you end up with is a flag that has the exact same effect as volatile. > But there are obviously people who think > there's no need in such option whatsoever, because "threaded code is > broken by definition, and I don't write it anyway". > > Even if mutithreading is of no immediate concern for you, it will > become tomorrow then you decide to run your loop on all 1024 cores > your cell phone provides. This is smug patronising nonsense. There are a lot of people around here who've been writing multithreaded code for decades. Not to mention multi-processor code. In both symmetric and asymmetric setups. With and without all kinds of coherent and non-coherent caching considerations to take into account. Please try not to claim that you are some kind of far sighted visionary preaching the future to a bunch of ignorami; we've all been doing it for years, and we do have a pretty good grasp of the concepts. > So you can't argue that this option > wouldn't be nice to have, no? I haven't needed it yet. I mark my volatile variables as volatile, rather than expecting the compiler to treat all variables the same indiscriminately. You're right that volatile doesn't solve the whole problem; you still have to write correctly threadsafe code, you still have to use locks, and you still have to be aware of the huge complexities of lock-free code, but what it does give you is the essential tool you need from the compiler for that: a strict one-to-one relationship between the loads and stores in your high level source and those in the emitted assembler. > And as I understood this discussion, there will be such option in GCC > in the nearest future. Well, as I don't mind confirming once more, if you really want -fshoot-yourself-in-the-foot, you're welcome to it. cheers, DaveK -- Can't think of a witty .sigline today....