P2545 Why RCU Should be in C++26

[wg21bot]

P2545R0 Why RCU Should be in C++26 (Paul E. McKenney, Michael Wong, Maged M. Michael, Geoffrey Romer, Andrew Hunter, Arthur O’Dwyer, Daisy Hollman, JF Bastien, Hans Boehm, David Goldblatt, Frank Birbacher, Erik Rigtorp, Tomasz Kamiński, Jens Maurer)

[brycelelbach]

Let's let SG1 look at this first.

[ogiroux]

Forward the RCU design of P2545 to LEWG for IS26
SF F N A SA
4 4 0 0 0

[brycelelbach]

2022-09-20 Library Evolution Telecon

P2545R0: Why RCU should be in C++26

2022-09-20 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Minute Taker: Steve Downey

Champion: Paul McKenney

Start: 2022-09-20 11:10 Eastern

Does this paper have:

• Examples?
  • No.
• Field experience?
  • Implementation experience?
    • Yes, in Folly since 2017, but not in a Standard Library.
  • Usage experience?
    • Yes, in Folly since 2017, but not in a Standard Library.
  • Deployment experience?
    • Yes, in Folly since 2017, but not in a Standard Library.
• Performance considerations?
  • Not described in detail in the paper.
• Discussion of prior art?
  • Yes, but it could be expanded. The paper should list more examples of RCU usage and usage of things similar to RCU.
• Wording?
  • Yes, but it needs updating.
• Feature test macro?
  • No.

This feature was written for the Concurrency TS v2. The core paper (P1122) was reviewed by Library and plenary approved for the Concurrency TS v2 at the 2021-06 plenary.

The wording in this paper may not reflect the latest version for the Concurrency TS v2; some later fixes haven't been incorporated (P2396).

The wording also needs to be updated to target the IS instead of a TS (e.g. std:: instead of std::experimental::).

The wording may need to be updated to reflect current best practices. In some places, concepts should be used instead of type requirements (move_assignable, etc).

Should rcu_retire defer to the member function retire if its available?

Big Open Questions:

• What questions did we want the TS to answer?
  • The paper has a list.
  • How do we do async RCU? There's not much field experience with that.
  • Do multiple RCU domains make sense for C++?
  • Do we need special-purpose RCU implementations?
  • Do we need lower level efficiency API?
• Do we have answers to those questions?
  • The proposal suggests that the questions are for things that would
    build on top of the core features. The authors believe the core
    features are solid and don't have open design questions.
• If we add RCU to the IS, do we also want to include it in the TS?
  • No. We'd just want to add any additions that build on top and have open
    questions.

POLL: RCU should target the International Standard instead of the Concurrency Technical Specification v2.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
10	7	1	2	0

Attendance: 25

# of Authors: 4

Author Position: 4x SF

Outcome: Consensus in favor.

WA: More fleshed out motivation could change my A to F.

WA: More evidence of existing practice might change my mind.

End: 12:03

Summary

This proposal advocates for moving the core RCU features proposed for the Concurrency TS v2 to C++26. The authors believe that the core features are solid. They claim all the questions we hoped to answer in the TS relate to things that we'd build on top of this core set.

Library Evolution was in favor of this direction. However, some updates need to be made to the wording in the paper, as they do not reflect the latest proposals modifying the Concurrency TS v2 draft.

Next Steps

Revise the paper and return to Library Evolution for further design review.