Closed libbooze closed 2 years ago
I for one was thinking that maybe the
T
itself needs to bestd::atomic<SomeOtherT>
.
std::atomic<T>{NIL}.is_lock_free()
must be true
for T
to be considered atomic and lock-free. You are right that the documentation wording may be less than ideal. I am open to your pull requests.
I for one was thinking that maybe the
T
itself needs to bestd::atomic<SomeOtherT>
.
That calls for explicitly deleted queues partial specializations for std::atomic<T>
, which makes good sense.
Not sure if that
assert
could bestatic_assert
, IDK if there can be a type thatis_lock_free
but not constructible at compile time.
static_assert
would be ideal for that, you are quite right. https://en.cppreference.com/w/cpp/atomic/atomic/is_lock_free is not constexpr
, sadly, which precludes from using it in static_assert
.
C++17 offers another option https://en.cppreference.com/w/cpp/atomic/atomic/is_always_lock_free, which I may add in the future, unless someone submits a pull request for that earlier.
As a side note, I would like to encourage you to always try out your own suggestions and submit successful ones as pull requests. Pull requests is often the best way to complain and having your complaint resolved fastest.
Thank you for your pull request.
I minimized the wording, added a few more words and moved the links to the bottom, and submitted a new commit only to not have to update yours.
If you are happy you may like to close this issue. Otherwise, let me know.
I like your changes better, thank you very much for fixing this.
I found this in source, but it was not obvious from reading the docs:
assert(std::atomic<T>{NIL}.is_lock_free()); // This queue is for atomic elements only. AtomicQueue2 is for non-atomic ones.
I for one was thinking that maybe the
T
itself needs to bestd::atomic<SomeOtherT>
.P.S. Not sure if that
assert
could bestatic_assert
, IDK if there can be a type that is_lock_free but not constructible at compile time.