Notes on 29 Oct 2018 Meeting

[Michael Spear]

Hello Everyone,

Michael Scott, Hans Boehm, and Mike Spear called into the meeting.  As with the previous call, we did not have enough people for a quorum, and we didn't have an agenda, but we reviewed some details and outlined some steps going forward.

The main task was discussion of TMLite.  We have a document (attached), which isn't really in the proper format, but it could be the start of a TMLite document (technically, it is a hasty user manual for the TM system from Lehigh). 

We discussed the following two issues, where the attached document may not be what we want for TMLite:

1 - Static checking - In our discussions of TMLite, we seemed to favor statically checking certain properties (no calls to functions outside of the translation unit; no syscalls, atomics, or volatiles, etc.).  The alternative would be to serialize in those cases.  We discussed how pragmatism favors the latter: a programmer might want to insert some printf debugging, or an assert, in a transaction.  Static checking forbids these approaches.  Note that the two are equivalent in terms of implementation effort.  In any case where one compiler would insert a serialization instruction, the other would output an error.  Note: No decision was made, since we did not have a quorum.

2 - Memory model - In the TMTS, synchronized blocks have the same ordering as locks.  Atomic blocks do not.  The attached document claims lock-based semantics, but it is sloppy, and does not precisely say how its TM proposal interacts with the memory model.  Note: No decision was made, since we did not have a quorum.

I think that summarizes the discussion to a satisfactory degree.  If any attendee wishes to correct or expand upon anything in this email, please do.

We anticipate that the next call will be on Monday, 12 November.

- Mike

[Michael Spear]

(A quick follow-up from Hans that I didn't see before sending the above email)

"We currently treat atomic and synchronized blocks identically in this respect.

"The TS currently says

"The start and the end of each synchronized block or atomic block is a full-expression (1.9 [intro.execution]). A synchronized block (6.9 [stmt.sync]) or atomic block (6.10 [stmt.tx]) that is not dynamically nested within another synchronized block or atomic block is called an outer block. [ Note: Due to syntactic constraints, blocks cannot overlap unless one is nested within the other. ] There is a global total order of execution for all outer blocks. If, in that total order, T1 is ordered before T2,

" — no evaluation in T2 happens before any evaluation in T1 and

"— if T1 and T2 perform conflicting expression evaluations, then the end of T1 synchronizes with the start of T2. "

[Michael Wong]

Hi all. Thank you for still holding the call. I messed up my parity again and thought we were on an out of cadence week, even though I was actually home this week unlike the last 2 weeks.

--
You received this message because you are subscribed to the Google Groups "SG5 - Transactional Memory" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tm+unsu...@isocpp.org.
To post to this group, send email to t...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/tm/.