pt., 7 lip 2023 o 10:19 1one1 via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Friday, July 7, 2023, 04:13, 1one1 <ahshabazz_at_[hidden]> wrote:
>
> Okay. Let's start with an API declaration followed by a usage example, if you will indulge me, for a moment:
>
> #include <iostream>
> #include <fiber> // hypothetical header
>
> // The proposed syntax for std::fiber<T> could be:
> template < typename BaseType >
> std::fiber< BaseType > FiberName;
>
> Here, `FiberName` is the name of the new fiber; and `BaseType` is an existing C++ type;
>

And what is this exactly? How is this "syntax" for fiber?


> // A proposed usage example:
> int main() {
>
> std::fiber<int> ctx {10};
>
> std::fiber<int> fiber1([&](std::active_fiber_context<int>& _) {
> ctx.data += 1; // Operations on "data"... COW semantics in action - only fiber1's "data" member is changed.

And where is this COW data stored? What is exactly `data` there? `int`??
Besides, why does it use `ctx` there? Why does `std::fiber` work as
somychonziation primitive and thread at same time?

> ctx.shared(); // share "data" with other fibers
> std::cout << "Fiber 1: " << ctx.data << std::endl; // 16
> });
>
> std::fiber<int> fiber2([&](std::active_fiber_context<int>& _) {
> // fiber2 now sees "data" as 11 initially, due to sharing

No, it will see 10 as `fiber1` could not run yet.

> ctx.data += 5; // COW semantics in action - only fiber2's "data" member is changed
> ctx.shared();

And how `shared()` will fix the case when one fiber has 11 and other has 15?

> // More operations on unrelated "data"...
>
> std::cout << "Fiber 2: " << ctx.data << std::endl; // 16
> });
>
> fiber1.join(); // Or implicit join() upon destruction
> fiber2.join(); // Or implicit join() upon destruction
>
> return 0;
> }
>

Looking at this code I suspect its indeed ChatGPT (like Fabio noticed),
it looks fine on the surface but when you dig deeper you will see that
it has no deeper meaning.

>
>
>
>
> On Friday, July 7, 2023, 03:37, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
>
> On Fri, 7 Jul 2023, 08:05 1one1 via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>
>
> **Title:** Proposal for `std::fiber<T>` Language-Level Extension in C++23
>
> **Document number:** N/A
>
> **Date:** 2023-07-07
>
> **Project:** Programming Language C++
>
> **Reply to:** ahshabazz_at_[hidden]
>
> **Introduction**
>
> Dear Members of the C++ Standards Committee,
>
> This document proposes a novel language-level extension to the C++ Standard Library, namely `std::fiber<T>`, aimed to ease and optimize concurrent programming by providing automated management of shared state.
>
> ## Motivation and Scope
>
> Concurrent programming is a challenging aspect of C++, requiring careful synchronization to avoid data races and associated undefined behavior. This proposal seeks to mitigate these challenges by introducing a unit of execution, `std::fiber<T>`, designed with built-in Read-Copy-Update (RCU) or Copy-On-Write (COW) semantics to handle shared state. This approach simplifies concurrent programming, allowing programmers to reason about each fiber's execution as if it were single-threaded, whilst the complexity of managing shared state is handled by the language or runtime.
>
> ## Proposal
>
> We propose `std::fiber<T>`, as a lightweight unit of execution with its own private data `T`. Each fiber would employ RCU or COW semantics when sharing data with other fibers, minimizing data races while optimizing memory usage and execution speed.
>
> To address the many challenges associated with thread management, we propose the following solutions:
>
> 1. **Performance Overhead**: Apply "lazy copying" and diffing techniques, where data is copied only when it's about to be modified, and only the parts of the data that have changed are copied and updated.
>
> 2. **Synchronization**: Use efficient lock-free algorithms, where possible, to manage synchronization, and design flexibility into the API to allow advanced users to apply manual synchronization when necessary.
>
> 3. **Garbage Collection**: Implement deterministic memory management, such as reference counting or region-based memory management strategies, or consider employing a simple garbage collector specifically for managing the lifetimes of these shared data structures.
>
> 4. **API Design**: Design the `std::fiber<T>` API such that certain variables can be marked as shared, possibly with a keyword or physical annotation. Alternatively, all variables in a fiber could be private by default, with explicit sharing of variables only as required.
>
> 5. **Semantic Complexity**: Provide comprehensive documentation, usage examples, and tooling support (like static analysis tools) to assist developers in understanding and effectively using `std::fiber<T>`.
>
> ## Impact on the Standard
>
> This proposal does not anticipate any breaking changes to the existing C++ standard, as `std::fiber<T>` would be a new addition that complements the existing concurrency model.
>
> The addition of `std::fiber<T>` would likely involve modifications to the C++ memory model to account for the proposed RCU or COW semantics. Further, to accommodate the garbage collection strategies, modifications may be required in the language's resource management model.
>
> ## Future Directions
>
> Following the adoption of `std::fiber<T>`, we suggest exploring these areas of further optimizations, such as fine-tuning the garbage collection strategy, enhancing the lock-free algorithms, or refining the copy strategies. We also recommend developing further tooling support to aid in the effective use of `std::fiber<T>`.
>
> We hope this proposal will be considered for inclusion in the C++23 standard.
>
>
> Nothing else can be included in C++23 now, that deadline passed about a year ago.
>
>
> We look forward to your feedback and are ready to revise and refine this proposal based on the committee's suggestions.
>
>
> This isn't really a proposal, it's just an idea. Arguably not even that, just a name, "fiber<T>".
>
> You haven't explained how to use it, what the API looks like, how it's different to other approaches.
>
> It's premature to talk about lock-free algorithms and garbage collection strategies when you don't actually have a proposal yet.
>
> Fewer buzzwords and more information, please.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals