Notes on 15 Oct 2018 meeting
6 views
Skip to first unread message
Victor Luchangco
Oct 15, 2018, 4:34:53 PM10/15/18
to t...@isocpp.org
Hi folks,
Michael Scott, Hans Boehm, and I called into the meeting (there seemed to be someone else who called in on a phone, but never actually identified themselves), and though we weren’t really a quorum, and we didn’t have an agenda, we reminded ourselves of what we think we agreed on and what we need to do. I think our last meeting was all the way back on August 20, so I took this secretary rota from there (and moved myself to the end):
Maged, Jens, Michael Scott, Michael Spear, Michael W, Hans, Victor
First, Mike Spear did send Herb Sutter a draft TM support proposal based on the LLVM-based plug-in that he and his students developed at Lehigh, so that Herb could share this with Tim Sweeney when they met last month. It would be great to hear any feedback that Herb or Tim has about the proposal.
Second, we agreed that the next step was to write a stripped-down proposal, or actually two: one that would be to explain the feature to programmers, and the other would be language to amend the actual specification. I think for now, we should focus on the first, but it may be that the second will consist primarily of stripping stuff out of the old TS.
We couldn’t remember whether we had decided to go with a library interface (i.e., start a transaction by passing a lambda to a library function) or introduce an atomic block. I thought the latter, but I’m not sure, and our prototypes are likely to have a library interface in any case (certainly the Lehigh plug-in is so). That said, it will require some compiler support, because it needs to check that the only memory accesses within a transaction are ordinary reads and writes. The goal is to have a proposal that is easy to implement and easy to explain. We want something that is useful for noncontrived applications, even though it may not be useful for all the various ways that various of us would like to use them. But we also want to make design decisions that do not foreclose these other uses.
Some other aspects:
- No explicit limit on the number of accesses within a transaction, but definite guidance that fewer is better, analogous to guidance that smaller critical sections are better.
- Only ordinary reads and writes: no access to volatiles, locks, atomics, etc.
- Local computation and control flow (e.g., if statements, loops, switch statements) are okay.
- No exceptions can be thrown within a transaction (even if it is caught within the transaction).
- Function calls are okay provided that their definition is available (and the function body satisfies the constraints above). We can leverage the language for const-expr functions.
We may also want to provide a list of some extensions to consider, such as allowing locks or atomic accesses within a transaction, or allowing functions declared to be transaction-safe (as in the TS), or dealing with exceptions. But even if we can implement these without run-time performance penalty, we aren’t including them for now. We can decide what to actually add based on feedback from user experience.
Michael Scott suggested that we could have an NCAS library function, which might be useful if a programmer wanted to do their own plumbing for some reason. It is trivial to add this to a proposal that has transactions (since NCAS is trivial to implement as a transaction). The only "difficulty” is deciding on the interface. Providing this function might also be useful as a way to get people to start to exploit TM without having to think at all about transactions (and in some cases, it might be easier to provide just the NCAS library function).
Hans said we should try to provide an implementation that provides some benefit to the programmer even if there is no hardware TM support; that is, we shouldn’t always just fall back to a single global lock. Certainly some STM seems appropriate in such cases. And if we can establish static separation of the locations accessed by a set of transactions, then they could be protected by their own lock. In any case, we don’t provide any performance guarantees, so all this amounts only to some kind of guidance to give programmers and implementors.
That’s all I remember now. Michael, Hans, please add/correct anything that I may have inadvertently omitted or misstated.
- Victor
Michael Scott, Hans Boehm, and I called into the meeting (there seemed to be someone else who called in on a phone, but never actually identified themselves), and though we weren’t really a quorum, and we didn’t have an agenda, we reminded ourselves of what we think we agreed on and what we need to do. I think our last meeting was all the way back on August 20, so I took this secretary rota from there (and moved myself to the end):
Maged, Jens, Michael Scott, Michael Spear, Michael W, Hans, Victor
First, Mike Spear did send Herb Sutter a draft TM support proposal based on the LLVM-based plug-in that he and his students developed at Lehigh, so that Herb could share this with Tim Sweeney when they met last month. It would be great to hear any feedback that Herb or Tim has about the proposal.
Second, we agreed that the next step was to write a stripped-down proposal, or actually two: one that would be to explain the feature to programmers, and the other would be language to amend the actual specification. I think for now, we should focus on the first, but it may be that the second will consist primarily of stripping stuff out of the old TS.
We couldn’t remember whether we had decided to go with a library interface (i.e., start a transaction by passing a lambda to a library function) or introduce an atomic block. I thought the latter, but I’m not sure, and our prototypes are likely to have a library interface in any case (certainly the Lehigh plug-in is so). That said, it will require some compiler support, because it needs to check that the only memory accesses within a transaction are ordinary reads and writes. The goal is to have a proposal that is easy to implement and easy to explain. We want something that is useful for noncontrived applications, even though it may not be useful for all the various ways that various of us would like to use them. But we also want to make design decisions that do not foreclose these other uses.
Some other aspects:
- No explicit limit on the number of accesses within a transaction, but definite guidance that fewer is better, analogous to guidance that smaller critical sections are better.
- Only ordinary reads and writes: no access to volatiles, locks, atomics, etc.
- Local computation and control flow (e.g., if statements, loops, switch statements) are okay.
- No exceptions can be thrown within a transaction (even if it is caught within the transaction).
- Function calls are okay provided that their definition is available (and the function body satisfies the constraints above). We can leverage the language for const-expr functions.
We may also want to provide a list of some extensions to consider, such as allowing locks or atomic accesses within a transaction, or allowing functions declared to be transaction-safe (as in the TS), or dealing with exceptions. But even if we can implement these without run-time performance penalty, we aren’t including them for now. We can decide what to actually add based on feedback from user experience.
Michael Scott suggested that we could have an NCAS library function, which might be useful if a programmer wanted to do their own plumbing for some reason. It is trivial to add this to a proposal that has transactions (since NCAS is trivial to implement as a transaction). The only "difficulty” is deciding on the interface. Providing this function might also be useful as a way to get people to start to exploit TM without having to think at all about transactions (and in some cases, it might be easier to provide just the NCAS library function).
Hans said we should try to provide an implementation that provides some benefit to the programmer even if there is no hardware TM support; that is, we shouldn’t always just fall back to a single global lock. Certainly some STM seems appropriate in such cases. And if we can establish static separation of the locations accessed by a set of transactions, then they could be protected by their own lock. In any case, we don’t provide any performance guarantees, so all this amounts only to some kind of guidance to give programmers and implementors.
That’s all I remember now. Michael, Hans, please add/correct anything that I may have inadvertently omitted or misstated.
- Victor
Michael Wong
Oct 15, 2018, 6:54:56 PM10/15/18
to SG5 - Transactional Memory
THank you for continuing the call. MY apologies as I messed up my time zones while on a flight Toronto to San Francisco (just landed now) and thought I would be OK to do the call on landing at 4pm, but forgot that it was pacific time. By the time i realized my mistake, I saw that my flight had no in flight wifi and could not notify anyone. sorry about that.
Reply all
Reply to author
Forward
0 new messages