Notes on Aug 6 meeting

4 views
Skip to first unread message

Victor Luchangco

unread,
Aug 15, 2018, 1:32:19 PM8/15/18
to t...@isocpp.org
Hi folks,

Sorry I didn't send this out sooner.

- Victor


"Minutes" for SG5 meeting on 6 Aug 2018

I was supposed to take minutes for this meeting, but then mostly forgot to take notes during the meeting, so I apologize for the incompleteness.  I hoe this captures the gist, which is that we agreed in principle with what we want to specify as a first step for a stripped-down version of TM.

Participants: Mike Spear, Michael Scott, Herb, Hans, Victor

Secretary rota: Maged, Jens, Hans, Michael Scott, Michael Spear, Michael W, Victor

Mike Spear raised questions about how restrictive we want to be within atomic blocks:

- disallowing function calls discourages good modular programming
- what constitute "ordinary reads and writes"?  what about atomics, volatiles?
- what is the purpose of these restrictions?

Herb: 
- Not opposed to allowing more functionality in principle, but want to start with minimal useful proposal. 
- Ordinary memory accesses are defined: they do not include atomics or volatiles.  (Volatiles may be changed asynchronously, so it probably will never make sense to allow transactional access.)  
- Perhaps we can use the wording for auto return functions to determine whether a function can be called within an atomic block.
- The goal is to have something easy to teach.
- Tim Sweeney is interested in having this functionality to use in Fortnite.

Michael Scott?: 
- What about exceptions? (No, exceptions involve synchronization.)
- What about control flow (e.g., ifs, loops)?  (These should be fine since there is no limit to the number of access in an atomic block.)

Summary of what we want in the proposal:

Introduce atomic block (contextual keyword).
Only ordinary memory accesses: no volatiles, atomics, etc.
  - may want to add atomics in the future, but keep it simple for now.
Local control flow (e.g., for loops, if statements) are allowed.
Primitive operations (e.g., addition, multiplication) are allowed.
No synchronization, throw statements, system calls, etc.
Only call functions that can be checked to obey restrictions.
 - perhaps require functions to be auto return value functions, so that the restrictions can be checked

Action Item: Victor and Mike Spear will work on preparing a more complete draft description (i.e., in vernacular, not necessarily in the language of the specification).

Next meeting: Aug 20.


Reply all
Reply to author
Forward
0 new messages