A couple of comments that occurred to me after the fact:

1. Looking at the specification of synchronized_pool_resource (which I think is what we were talking about), I think it's synchronization characteristics are underspecified. But if they were fully and correctly specified then it should probably not be usable inside transactions. Alternatively, it could perhaps get malloc-like treatment, but that seems overkill for something I haven't yet seen used.

2. We unfortunately didn't get around to shared_ptr/weak_ptr. Reference counts can be observed with either use_count() or weak_ptr, so I think they have to be excluded. Are there any other library facilities that need to be excluded because they use shared_ptr or the like internally? Std::future presumably doesn't count because it's already excluded?


On Tue, Mar 9, 2021 at 1:57 PM Hans Boehm <boehm@acm.org> wrote:
Attendees: Hans Boehm, Victor Luchangco, Jens Maurer, Michael Scott, Mike Spear

We discussed the state of P1875 and P2066, trying to ascertain whether things are in sufficiently consistent shape.

What's the role of the "inline function with reachable definition" restriction?

The position at the end of the last meeting was essentially that we preserve this for unknown user functions, but generally require most of the standard library to be supported, even if the implementation violates this constraint.

There is clearly a tension here: Once we support various library calls that require fallback to a global lock when they do difficult things, why don't we just require the compiler to do the same?

What about std::function, which can essentially replace function pointers?

In the end, we decided to stick to this for now: We don't require the compiler to implement a fallback, but the standard library code may have to. This will clearly be revisited again. It should avoid the need for more than syntax-level compiler support for an HTM-based implementation. 

Other library functions that should probably be disallowed because they involve visible synchronization:
synchronized_pool_resource, signal(), Handler functions (e.g. terminate), time zones?

Other library functions that relate to function pointers like std::function and std::bind should be allowed.

Action Items:

Jens to update and submit P2066

Hans to update P1875, if needed.

Next meeting: Tuesday April 6, 8am PDT / 11:00am EDT


 +1 208-925-0196‬ PIN: ‪255 542‬#