Date: Fri, 10 Jan 2020 09:48:51 -0500
On Jan 9, 2020, at 6:24 PM, Hans Boehm <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
> 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
Received on 2020-01-10 08:49:17