C++ Logo


Advanced search

Subject: September 22 meeting
From: Hans Boehm (boehm_at_[hidden])
Date: 2020-09-21 20:07:05

Let's go ahead and meet tomorrow at 8:00 PDT/11:00 EDT as scheduled to
discuss progress, and possibly questions about malloc/new.

Join with Google Meet
Join by phone
‪(US) +1 208-925-0196‬ PIN: ‪255 542‬#

On Tue, Aug 25, 2020 at 6:28 PM Hans Boehm <boehm_at_[hidden]> wrote:

> Attendees:
> Hans Boehm
> Bronek Kozicki
> Victor Luchangco
> Jens Maurer
> Michael Scott
> Mike Spear
> Michael Wong
> We discussed feedback from EWG
> The initial discussion was about alternate keywords or
> context-sensitive-keywords to replace the current ambiguous atomic {}
> syntax.
> Bronek reminded us of the difficulty with "do atomic {":
> do do atomic { ... } while (...) is legal and hard to parse.
> Explained that even a relatively obscure new keyword like tm_atomic was
> likely to cause problems with existing codebases.
> There was lukewarm consensus (ambivalence?) on atomic do.
> Jens summarized EWG discussion and explained why constexpr is not a good
> indicator of transaction-safety. We increasingly have constexpr functions
> that test for a constexpr constant and execute different, possibly
> non-transaction-safe, code in other cases.
> Talked about what we really needed to be transaction-safe.
> memcpy, memset should be.
> STL containers are the problem.
> For something like vector, it's possible to get a pointer to a C array
> outside the transaction. But that fails if multiple containers are
> accessed, with one referring to the other.
> Traits are OK. Numeric limits, too. Constexpr values in general. What's
> the best way to characterize purely compile-time expressions?
> For something like std::vector, should we be limited to accessors? Can we
> grow containers inside transactions? Should malloc/new be supported?
> General initial reaction: Should not be required.
> Mike Spear argues for malloc/new. Easily supported for HTM and global
> lock. For STM, not that much more work is required.
> What about throwing OOM? Currently no throws in transactions are allowed,
> even non-escaping ones.
> Action Items:
> Jens will generate new revision with minimal guaranteed standard library
> support.
> Mike Spear will try to write up a short paper describing why malloc
> support is easy.
> Next meeting scheduled for 8:00 PDT, Sept. 22

SG5 list run by sg5-owner@lists.isocpp.org

Older Archives on Google Groups