Hi Jens,

Thanks. For the "forbidden" list, using the nomenclature of
cppreference.com, I think we must forbid the Thread Support, Atomic
Operations, Filesystem, Input/Output, and Localizations libraries. Does
that sound right to you?

- Mike

On Wed, Oct 21, 2020 at 5:01 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:

> On 21/10/2020 22.50, Michael Spear wrote:
> > Thanks Jens. I think writing another paper would subsume the preceding
> draft, which focused on allocation. One concern I have is that I don't
> really know the right style/tone/level of detail for such a paper for this
> audience. Do you know of any examples that I might be able to reference?
>
> Don't be intimidated by the word "paper". I don't know any specific
> examples; sorry. However, it needs to contain
>
> - the three implementation choices (HTM, STM, single global lock) with
> a bit of non-expert explanation what it does
> - why support for exceptions and memory allocation is easy in each of
> those (your e-mail text, essentially)
> - the conclusion that SG5 wishes to bring forward a TM feature set
> for the next TS that includes all of the standard library, except
> (your list)
>
> If it ends up being just one or two pages, all the better.
>
> Jens
>
>
> > - Mike
> >
> > On Wed, Oct 21, 2020 at 4:48 PM Jens Maurer <Jens.Maurer_at_[hidden]
> <mailto:Jens.Maurer_at_[hidden]>> wrote:
> >
> > On 21/10/2020 15.54, Michael Spear via SG5 wrote:
> > > If an implementation protects all transactions with a single,
> global, reentrant lock, then there are three pieces to the implementation.
> > > - The first is modifying the parser to support the new syntax.
> This is common to any implementation, so whatever effort it entails is
> really a fixed cost for the TS.
> > > - The second is some kind of run-time library that maps the
> beginning and end of a lexically scoped transaction to operations for lock
> acquire and lock release. This is quite simple.
> >
> > Agreed so far.
> >
> > > - The third is whatever static analysis is needed to warn
> programmers when their atomic blocks do something forbidden. This may be
> difficult, depending on how we specify things. For example, if the
> compiler *must* warn when an exception escapes a transaction, then if the
> compiler does not have access to definition of a function that might throw,
> how could it give such a warning?
> > >
> > > My guess is that the third piece is going to be "best effort" by
> the compiler writer. Surely some things should produce warnings, but with
> an understanding that there might be false negatives (e.g., we miss a
> warning for a transaction that has undefined behavior, because the
> transaction spans TUs and in some other TU, it uses std::cout or a
> std::atomic variable, or opens a socket, or does something else that can
> legally constitute inter-thread communication).
> >
> > My guess is there will be close to zero warnings.
> > As you correctly observe, there are implementability concerns
> > for required warnings on e.g. exceptions escaping an atomic
> > block. As a consequence, no warnings will be required.
> > (And if we could require warnings, we'd make them errors,
> > because if we can say for sure that bad code is executed,
> > we'd better refuse to compile.)
> >
> > > In the case of throw, the expression of exceptions in the
> intermediate representation is via function calls or intrinsics (cxa_throw,
> cxa_catch, LLVM landing pads, etc). The implementation of these is
> dependent on the OS and architecture. For example, IIRC on Linux targets
> they traverse DWARF tables within the binary itself. So, again, making
> assumptions about these is not portable, and correct programs cannot assume
> anything more than the high-level specified behavior. That behavior is
> little more than "nonlocal jump, with destruction of everything on the
> popped part of the run-time stack". Note: if I am wrong, and the behavior
> of stack unwinding is more carefully defined, and that definition includes
> the possibility of stack unwinding being a legal form of inter-thread
> communication, then my whole argument is invalid. Hopefully someone more
> knowledgeable about exceptions in C++ can confirm or refute my claim.
> >
> > Stack unwinding is properly defined, but it does not have
> inter-thread
> > impact per se. Something like std::lock_guard's destructor unlocks a
> > mutex, of course, but these inter-thread communication mechanisms
> should
> > not be allowed in an atomic block regardless.
> >
> > > In the original TMTS, exceptions are tricky because there need to
> be writes to the exception object, and these writes need to be instrumented
> in a special way, because these writes can escape the transaction even if
> the transaction gets undone. In the proposed TMTS, exceptions cannot
> escape a transaction (and the transaction doesn't ever have to get undone),
> which means that STM can fall back to a single lock whenever it encounters
> a throw. This is easy to do, because the STM instrumentation pass simply
> says "here's a function for which I don't have a definition... I guess I'll
> just serialize the transaction here". cxa_throw is no different than a
> multi-TU transaction.
> >
> > Agreed.
> >
> > > If we *wanted* to specify commit-on-exception-escape, it would be
> trivial to support in a reasonable TM implementation. I don't think we
> want to, and I'm in favor of forbidding exceptions from escaping
> transactions. However, the use of exceptions within a transaction does not
> appear to pose an implementation challenge, nor does it appear to pose a
> correctness challenge.
> > >
> > > So, in summary, I do not see implementation issues with supporting
> throw+catch inside a transaction, or allocation inside a transaction. As
> the minutes state, this will open up a huge portion of the standard library
> to transactions (perhaps only threads, coroutines, mutexes, atomics, and
> iostreams would still be forbidden?).
> >
> > Sounds about right.
> >
> > As I said in the call, that's a rather sharp departure from the
> previous
> > approach "limited standard library functions are allowed", so needs
> an
> > accompanying rationale paper, stating approximately what's in your
> > e-mail, above.
> >
> > Jens
> >
>
>