3 ms·

There's clearly an opportunity for a much longer talk, this teases that Paul (McKenney, of Linux fame) will have a very different take and we don't hear what it

There's clearly an opportunity for a much longer talk, this teases that Paul (McKenney, of Linux fame) will have a very different take and we don't hear what it is, maybe that was presented at another session of this conference. It's definitely true that translating into "standardese" is a bad idea. Humans don't read standardese and neither do machines, a machine readable model would be superior (more likely to be correct, more easily tested) for this and for other tricky technical problems. Given that even the for-profit C++ vendors don't use the actual ISO document (it's out of date and pointlessly expensive so why bother) having an appendix to the "draft" with the machine proofs would be much better. I think Hans makes an understandable but (IMO) wrong assumption about a benefit from choosing Sequentially Consistent ordering (the C++ default) over caring which order is correct. Much of the tricky concurrent code non-experts are going to write against these APIs will be wrong anyway, even if you provide Sequential Consistency. As a result the committee's original assumption wouldn't have much helped. For example I doubt that when (if? I don't like some of the noises I've been hearing) Microsoft fixes SRWLock the fix will be an ordering tweak.

davidtgoldblatt 3y ago
> There's clearly an opportunity for a much longer talk, this teases that Paul (McKenney, of Linux fame) will have a very different take and we don't hear what it is, maybe that was presented at another session of this conference. Paul's talk is here: https://www.youtube.com/watch?v=iJP6DWVrLjM https://www.youtube.com/watch?v=iJP6DWVrLjM
- tialaramex 3y ago
  Thanks, I think I'll end up watching a good number of these
jcranmer 3y ago
There is a bit of a trend in languages to shift towards more formal semantics. In the C/C++ world, the relaxed memory model and the pointer provenance work are being heavily driven by actual formal semantics model. And many newer languages seem to rely on a more overtly operational semantics description (Java and JavaScript come to mind), although the C and C++ standards themselves are largely free of this. I definitely would like to see formal semantics be defined by the standards, although this is difficult because they still don't exist in complete form, and I'm not sure many committee members have an ability to read or reason about formal semantics very well. I think the commentary about the atomics memory model kind of not working as intended is useful to note. Consume is useless in practice, and there are probably better railings that could have been put around acquire/release semantics. I'll have to listen to several of the other talks.

davidtgoldblatt 3y ago

> There's clearly an opportunity for a much longer talk, this teases that Paul (McKenney, of Linux fame) will have a very different take and we don't hear what it is, maybe that was presented at another session of this conference. Paul's talk is here: https://www.youtube.com/watch?v=iJP6DWVrLjM https://www.youtube.com/watch?v=iJP6DWVrLjM

tialaramex 3y ago
Thanks, I think I'll end up watching a good number of these

jcranmer 3y ago

There is a bit of a trend in languages to shift towards more formal semantics. In the C/C++ world, the relaxed memory model and the pointer provenance work are being heavily driven by actual formal semantics model. And many newer languages seem to rely on a more overtly operational semantics description (Java and JavaScript come to mind), although the C and C++ standards themselves are largely free of this. I definitely would like to see formal semantics be defined by the standards, although this is difficult because they still don't exist in complete form, and I'm not sure many committee members have an ability to read or reason about formal semantics very well. I think the commentary about the atomics memory model kind of not working as intended is useful to note. Consume is useless in practice, and there are probably better railings that could have been put around acquire/release semantics. I'll have to listen to several of the other talks.