boostorg / boostorg/smart_ptr

Why is std::memory_order_relaxed enough for atomic_conditional_increment?

Open
#107 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
111
Forks
116
PR merge metrics
No merged PRs in 30d

Description

Hi, I'm just trying to understand the rationale behind the using of `std::memory_order_relaxed` in sp_counted_base_std_atomic.hpp's `atomic_conditional_increment`'s implementation.

atomic_conditional_increment's implementation (click to expand)

```
inline std::int_least32_t atomic_conditional_increment( std::atomic_int_least32_t * pw ) BOOST_SP_NOEXCEPT
{
// long r = *pw;
// if( r != 0 ) ++*pw;
// return r;

std::int_least32_t r = pw->load( std::memory_order_relaxed );

for( ;; )
{
if( r == 0 )
{
return r;
}

if( pw->compare_exchange_weak( r, r + 1, std::memory_order_relaxed, std::memory_order_relaxed ) )
{
return r;
}
}
}
```

AFAIK this function is used by `weak_ptr` to obtain the `shared_ptr` if the obj is still alive (ref count is still > 0).
Consider the following case:
```
shared_ptr A;
if ((A = weak_ptr.lock()) != nullptr) // internally does `if (atomic_conditional_increment() != 0)`
{
// modify object pointed by A
}
```

Shouldn't we use `std::memory_order_acquire` to ensure that the modification of object pointed by A won't be reordered before the `nullptr` check?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.