Please send agenda for today

11 views
Skip to first unread message

Michael Wong

unread,
May 7, 2018, 1:28:42 PM5/7/18
to victor.l...@oracle.com, s...@isocpp.org, t...@isocpp.org

Hi Victor I didn’t see meeting notes for the last sg5 call but assume there is a meeting today. If there is please send the agenda. If not then I will figure out the next one. Thank you for hosting.
Sent from my iPhone

Victor Luchangco

unread,
May 7, 2018, 2:24:44 PM5/7/18
to Michael Wong, s...@isocpp.org, t...@isocpp.org
Hi folks,

Sorry about this late notice. Last week, only Michael Scott and I called in, so we canceled the meeting.

I’ll set up the call for the meeting this afternoon. I’m just using stuff edited from a previous meeting
for the agenda, but one thing we need to discuss is what we want to do with meeting in the future,
as I’m leaving Oracle, and so I can’t host it in the future.

- Victor



Here’s the info:

Start Time: Monday, May 7, 2018, 12:00 PM US Pacific Time (07:00 PM in GMT)
End Time: 1:00 PM US Pacific Time (duration: one hour)

Toll-free Dial-in number: +1(866)682-4770
Local US number: +1(408)774-4073
Local Germany number: +49 89 1430 2323
(Let me know if you need a local number for a different country.)

Conference code: 8918244
Security passcode: 1234

With large numbers of participants, audio interference can be a problem. Please try to keep
your phone muted whenever possible. If your phone does not have a mute
button, the bridge will mute or un-mute your line if you dial *6.



The current secretary rota list is (the person who took notes at the
last meeting is moved to the end)



Maged,Jens, Victor,Michael W, Hans, Michael Scott,Michael Spear,



Agenda:

1. Opening and introductions

1.1 Roll call of participants

1.2 Adopt agenda

1.3 Approve minutes from previous meeting, and approve publishing previously approved minutes to ISOCPP.org

1.4 Review action items from previous meeting (5 min)

1.5 Call schedules (please add your away days)


May 7: this call; mailing deadline
May 21

June 4 RAP C++ Meeting


2. Main issues (50 min)



2.1 Future of TM proposal and this meeting



2.2: Interaction with Executors and Synchonized proposal

https://groups.google.com/a/isocpp.org/forum/#!topic/tm/jG9XPJetNkc

The last discussion has us considering an alternative lambda form.

See Paper emailed out on Lambda proposal

https://docs.google.com/document/d/1ICmcrCdigq3ataoM2Jl7m19h_Sa3aE3KfU6AVkPyT-4/edit#





2.3 future issues list:

1. llvm synrhonized blocks
2. more smart ptrs?how fast can atomics and smart ptrs be outside tx if they have to interact with tx (for world that does not care about tx), the atomic nature of smart ptrs as a way towards atomics inside atomic blocks
3. more papers?
4. Issue 1-4 paper updates to current TM spec
5. std library







2.4 Discuss defects if any work done since last call
Issue 1: https://groups.google.com/a/isocpp.org/forum/#!topic/tm/SMVEiVLbdig
Issue 2: https://groups.google.com/a/isocpp.org/forum/#!topic/tm/Th7IFxFuIYo
Issue 3:https://groups.google.com/a/isocpp.org/forum/#!topic/tm/CXBycK3kgo0
Issue 4: https://groups.google.com/a/isocpp.org/forum/#!topic/tm/Ood8sP1jbCQ




3. Any other business

4. Review

4.1 Review and approve resolutions and issues [e.g., changes to SG's working draft]
N4513 is the official working draft (these links may not be active yet until ISO posts these documents)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4513.pdf

N4514 is the published PDTS:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4514.pdf

N4515 is the Editor's report:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4514.html

Github is where the latest repository is (I have updated for latest PDTS published draft from post-Leneaxa):
https://github.com/cplusplus/transactional-memory-ts

Bugzilla for filing bugs against TS:
https://issues.isocpp.org/describecomponents.cgi


4.2 Future backlog discussions:

4.2.1 Write up guidance for TM compatibility for when TM is included in C++ standard (SG5)

4.2.2 Continue Retry discussion
https://groups.google.com/a/isocpp.org/forum/?hl=en&fromgroups#!topic/tm/qB1Ib__PFfc
https://groups.google.com/a/isocpp.org/forum/#!topic/tm/7JsuXIH4Z_A



4.2.3 Issue 3 follow-up

Jens to follow up to see if anything needs to be done for Issue 3.

4.2.5 Future C++ Std meetings:

2018 06-04 RAP C++ Std meeting


4.3 Review action items (5 min)



5. Closing process

5.1 Establish next agenda



5.2 Future meeting
Next call: TBD

Apr 9: this call
Apr 23
May 7 mailing deadline
May 21

June 4 RAP C++ Meeting

Victor Luchangco

unread,
May 7, 2018, 3:38:26 PM5/7/18
to t...@isocpp.org
Hi folks,

It was just Michael Scott and me on the call again this week, so we again called the meeting.

The next meeting would be just before the next C++ meeting, so I’m not sure if it’s more or less important that we meet then. Michael Wong, what do you think?

The main question we need to decide as a group is how we want to move forward. We had a great discussion a month ago with Herb on the phone, and I think there was general agreement about a possible path forward. In particular, if we could guarantee to (eventually) commit some kind of bounded transactions with only reads and writes (i.e., no function calls, etc.), that would be very useful. But we discussed whether we should restrict transactions so that the only ones that can be guaranteed to commit are legal, or if we should allow them to be more open-ended (but not guaranteed to commit in some cases) but still much more restricted than even the transaction-safe restriction we currently have for atomic blocks. For example, we might allow only reads and writes and simple local computation, disallowing any function calls, but not restrict the number of locations that may be accessed, leaving that as a quality of implementation issue.

Another issue that we need to resolve is how future calls will be hosted, as I won’t be able to host them in the future. Also, my Oracle email will cease to work, so I’ve changed my email address for this list to victor.luc...@gmail.com.

- Victor

Michael Wong

unread,
May 7, 2018, 9:40:28 PM5/7/18
to Victor Luchangco, t...@isocpp.org
Hi Victor, I am hoping this is good news. We now really need to decide what to do with the group. I can host for awhile using Codeplay's webex. But best of luck in your future position. Thank you for helping/hosting as I have been travelling for the last three weeks, and continue to do so next 2 weeks.

Michael Wong

unread,
May 21, 2018, 5:32:58 AM5/21/18
to SG5 - Transactional Memory
Hi all, I am still travelling this week and have not setup a webex for todays call though I could. Given that it is the only one before the C++ Std meeting, may I propose we do not do the call today, and restart after the Rapperswil meeting, unless there is urgent stuff we need to talk about (though I am 5 hour offset).
Thanks.

On Monday, May 7, 2018 at 3:38:26 PM UTC-4, Victor Luchangco wrote:
Hi folks,

It was just Michael Scott and me on the call again this week, so we again called the meeting.

The next meeting would be just before the next C++ meeting, so I’m not sure if it’s more or less important that we meet then.  Michael Wong, what do you think?

The main question we need to decide as a group is how we want to move forward.  We had a great discussion a month ago with Herb on the phone, and I think there was general agreement about a possible path forward.  In particular, if we could guarantee to (eventually) commit some kind of bounded transactions with only reads and writes (i.e., no function calls, etc.), that would be very useful.  But we discussed whether we should restrict transactions so that the only ones that can be guaranteed to commit are legal, or if we should allow them to be more open-ended (but not guaranteed to commit in some cases) but still much more restricted than even the transaction-safe restriction we currently have for atomic blocks.  For example, we might allow only reads and writes and simple local computation, disallowing any function calls, but not restrict the number of locations that may be accessed, leaving that as a quality of implementation issue.

Another issue that we need to resolve is how future calls will be hosted, as I won’t be able to host them in the future.  Also, my Oracle email will cease to work, so I’ve changed my email address for this list to victor.luchangco.work@gmail.com.
Reply all
Reply to author
Forward
0 new messages