Timeline for Single producer single consumer wait-free object container
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 16, 2018 at 8:11 | comment | added | papagaga | @purefanatic: you don't need to release 'the atomic'. I don't believe it allocates memory in the first place, and if it did, its destructor would be called automatically. That's the beauty of RAII. | |
| Oct 13, 2018 at 23:27 | comment | added | purefanatic | @Quuxplusone I also like the trailing underscores because when editing a method, I immediately see which variables are private members. | |
| Oct 13, 2018 at 23:22 | comment | added | purefanatic |
Regarding exception safety I think that exceptions in write or read are still not safe because the atomic is not released afterwards. But I could be wrong. One would have to make a RAII wrapper around the atomic or catch and re-throw. Both seem like quite a hassle for tiny reward, so I will likely settle with additional requirements for the user: noexcept copy/move construction, noexcept functors, reading the last value before destruction. I could statically enforce the noexcepts using std::is_nothrow_.... Not always being destructible reminds me of std::thread which should be fine imo.
|
|
| Oct 13, 2018 at 22:56 | comment | added | purefanatic | What I really do like though is the template approach to reduce code duplication! | |
| Oct 13, 2018 at 22:53 | comment | added | purefanatic |
@papagaga I guess you are right, I should put more thought into object lifetime and exception safety. But I don't quite like the std::optional approach as it incurs additional overhead because the "occupied" state is duplicated. Also it requires T to have an assignment operator which is a stronger requirement than being copyable or movable by construction in my opinion.
|
|
| Oct 13, 2018 at 22:18 | comment | added | Quuxplusone |
Also, complete nit, but std::is_convertible_v<U, T> raises a tiny red flag because it's using a perfect-forwarding reference in a non-perfect-forwarding context. You meant std::is_convertible_v<U&&, T>, or even more relevantly, std::is_assignable_v<T&, U&&>. The further you go down that road, though, the more you can't avoid worrying about the behavior of mySpscObject.write(std::nullopt)... :)
|
|
| Oct 13, 2018 at 22:11 | comment | added | Quuxplusone |
Re "Don't clutter [member] variable names with [trailing] underscores" — I'd disagree. The advantage of uglifying your member-data names is that you can write e.g. void set_value(T value) { value_ = value; } in a natural way. It's a really easy way to never worry about shadowing again, and thereby save those few extra brain cells to devote to more productive tasks.
|
|
| Oct 12, 2018 at 12:14 | history | edited | papagaga | CC BY-SA 4.0 |
added 38 characters in body
|
| Oct 12, 2018 at 12:07 | history | edited | papagaga | CC BY-SA 4.0 |
point out memory leak
|
| Oct 12, 2018 at 12:01 | history | edited | papagaga | CC BY-SA 4.0 |
point out memory leak
|
| Oct 12, 2018 at 10:57 | history | answered | papagaga | CC BY-SA 4.0 |