I’m not sure I buy this characterization. I think “defined” behavior will be fairly straightforward: no exceptions, syscalls, synchronization, or thread management allowed in transactions at run time. I think we may be getting hung up on the desire for “performant” behavior -- and in particular on the desire to have the compiler alert us to potentially non-performant behavior. I think that’s likely to be a lost cause: in the end, we really can’t make any compile-time guarantees about performance. Any argument in favor of allowing an implementation to make an operation undefined needs to be based, I think, either on semantics (e.g., we don’t know how to specify reasonable behavior for locks inside transactions) or difficulty of implementation (or possibly of documentation) -- _not_ expected performance. I don’t yet see an argument around difficulty of implementation.

- Michael

> On Jan 10, 2020, at 10:04 AM, Michael Spear <mfs409_at_[hidden]> wrote:
>
> It seems we need two things:
> 1 - A broad definition of what is defined behavior. Michael seems to be working towards this.
> 2 - A definition of a statically checkable defined behavior. Hans seems to be working towards this.
>
> A programmer should be able to say "I know this is defined behavior, even if the compiler doesn't, so I'm willing to turn off some check (or not turn on some check) because my HTM is going to do the right thing". But a programmer should also be able to say "I need the compiler to guarantee that this is going to be defined behavior, so that I don't have a debugging nightmare later". In the latter case, overly rigid rules are ok... if they become too annoying, and the use case is too important, then we know it's time to upgrade the specification.
>
> - Mike
>
> On Fri, Jan 10, 2020 at 9:46 AM Michael L. Scott via SG5 <sg5_at_[hidden] <mailto:sg5_at_[hidden]>> wrote:
> On Jan 9, 2020, at 6:24 PM, Hans Boehm <boehm_at_[hidden] <mailto:boehm_at_[hidden]>> wrote:
>
> > As was pointed out in the meeting there seem to be two reasons to restrict calls to other translation units, probably by relying on constexpr, neither 100% convincing:
> >
> > 1) To accommodate STM or hybrid TM. I agree that there is no correctness issue with supporting such calls. But in the past, we had significant concerns about usability of such a system. You can't really tell whether you're getting an even minimally scalable implementation of a simple standard library call without knowing whether its implementation resides in the same TU, which is now not easily determinable, and may change with the next release.
>
> But in an implementation based on HTM and a fall-back lock (the principal target for TM-lite, I think), there is already no way to be sure whether an algorithm will scale -- e.g., whether its transaction write sets exceed hardware buffering capacity.
>
> > 2) It makes it easier for an implementation to report when a data-race-free atomic{} block isn't really atomic because it internally uses e.g. locks, and can thus communicate with other threads before the (now irrevocable) transaction commits. Without the restriction, this would presumably require dynamic tests associated with locks and atomics. With it, the checks could be restricted to TUs containing atomic blocks, e.g. by cloning code called from within transactions.
>
> But there’s already no way to tell at compile time whether a transaction will acquire a lock at run time. Dynamic checks will always be required if we want to catch all uses of locks in transactions. (Personally, I’m fine with undefined behavior.)
>
> > Another weak argument is that since you can know you are within a transaction, you could presumably generate more HTM-friendly code in some cases. I don't know whether that's an issue with any existing hardware. Are there useful compiler-generated instructions that always fail in some HTM implementation?
>
> Why is this an argument for a very small set of required-to-be-supported operations? One could always generate HTM-friendly code in the cases where it’s possible. I don’t see the argument for allowing an implementation to forbid external calls in the interest of enabling optimizations, unless we can come up with a case where allowing external calls would preclude optimizing transactions that don’t make such calls.
>
> > I agree that using constexpr is imperfect. And there are cases in which the library vendor will need to change their code to adapt. I think we're only proposing using constexpr for the standard library; for other libraries the theory is that the user can tell what's defined in the same translation unit.
>
> - Michael
> --
> SG5 mailing list
> SG5_at_[hidden] <mailto:SG5_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5 <https://lists.isocpp.org/mailman/listinfo.cgi/sg5>