On Thu, Jun 18, 2015 at 12:40:15PM +0200, Peter Zijlstra wrote: > On Thu, Jun 18, 2015 at 11:40:14AM +0200, Ingo Molnar wrote: > > > In what retarded use-case do unasked for speculative writes even make any > > sense > > beyond as a sadistic tool to make parallel, threaded code even more > > fragile??
Well, these are the compiler guys we are talking about, so why would you expect otherwise? Sorry, couldn't resist... ;-) They believe that all parallel threaded code should mark either all shared variables (but get memory barriers on all normal accesses) or all accesses. Their use case is that they would like to be able to continue carrying out single-threaded-safe optimizations on concurrent code. And speculative writes of that form are just fine in single-threaded code. And if you think -that- is bad, you should have seen the screaming and shouting when they were prohibited from stomping on unrelated variables. They used to do "write widening", where they might use a vector unit to do a store, then fix up the adjacent variables that were clobbered by a too-wide write. You just can't make this stuff up! Anyway, I am having an ongoing discussion with them on handling pre-existing code. It has been an "interesting" discussion, particularly the parts involving rcu_dereference(). > So what worries me most is the "Takeaways" from the document: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html > > Those read like a 'fuck you' to 30 years of concurrent code in C. Pretty much. I already told them that, and they will hopefully do better in the next version. Some of them were annoyed at me for telling them what they could do with their proposal to eliminate thread-local storage (TLS, similar to Linux kernel per-CPU variables), though JF Bastien was co-author with me on that paper. But perhaps he felt the need to kiss up to the people who were annoyed by the refusal to go along with their TLS-removal urge. > Sure, its nice and all that they finally have something that's > standardized, and this might be an option for new projects (in reality > it might only really be an option in another 5-10 years). > > But the active encouragement to break existing code is utterly fucked. Yep, I have to frequently remind them that most projects need to support old compilers. And I did point out that the commentary at the end of that document would not encourage adoption of C11. They of course felt this was unfair of me, so I have to thank you both for proving the correctness of my reply to them. Although you guys didn't use quite as many swear words as I would have expected. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
