Hi, I have received the following idea for a Google Summer of Code project, see the quotation from Paul McKenney below (I do not know myself where exactly it is from). I consider memory consistency models a very tough topic and so am doubly reluctant to just post it to wiki without having a mentor for it. On the other hand, with the right mentors it definitely can be quite a remarkable project with a big potential.
Paul, this may come as a surprise for you, but would you be willing to (co-)mentor such a project if there is a student brave enough to undertake it? C++ front-end guys, would you please consider co-mentoring this project if Paul was willing to do so? Anybody else interested in getting involved? Any other suggestions/comments? Thank you very much in advance, Martin -------------------- Start of forwarded message -------------------- Hi Martin, I don't think I have a mentor for this yet though I wonder if Paul McKenney could be persuaded for this from the memory model side and someone familiar with the C++ frontend on the GCC side ? <quote Paul> -- One could argue that compilers in fact implement the C and C++ memory_order_consume facility. However, all known compilers do so by promoting it to memory_order_acquire, which on weakly ordered systems can result in unnecessary memory-barrier instructions on your fastpaths, which might not be what you want. The reason for the promotion to memory_order_acquire is the difficutlies faced by compiler writers when attempting to trace dependencies at the C/C++ source-code level. In fact, there is a proposal to temporarily deprecate memory_order_consume [1]. So what is to be done? One proposal [2] restricts dependency chains to cases where it is difficult for the compiler to break them, and further requires that pointer variables carrying dependencies be marked. (This proposal also includes prototype wording for the C++ standard, a number of litmus tests, and some discussion.) Such marking might not go down well with the Linux kernel community, which has been carrying dependencies in unmarked variables for more than 15 years, so there is further informal proposal asking C and C++ implementations to provide a command-line option forcing the compiler to treat any pointer variable as if it had been marked. (Why informal? Because command-line options are outside of the scope of the standard.) There is a prototype implementation that obtains the functionality of memory_order_consume without actually using memory_order_consume, which is briefly described in a recent C++ working paper [3]. However, the committee was not all that happy with this approach, preferring marking of a single pointer variable to maintaining a separate variable to carry the dependency. It would therefore be quite desirable to have an implementation that allowed pointers to be marked as carrying dependencies, that avoided the specified dependency-breaking optimizations on such pointers, and that provided a command-line switch that caused the compiler to treat all pointers as if they were to marked [2]. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html --- Ramana -------------------- End of forwarded message --------------------
