以下代码中会有赛车情况吗？

Question

We know the destructor code below is supposed to release the control block if this is the last smart_ptr pointing to the resource being managed. Is it possible that we have a racing problem between the "if" and the "delete" below? what if we try to create a brand new smart_ptr obj in a different thread right right AFTER the "if" and BEFORE "delete"?

// Thread D:
// smart_ptr destructor
~smart_ptr() {
  if (control_block_ptr->refs.fetch_sub(1, memory_order_acq_rel) == 0) {
    delete control_block_ptr;
  }
}

Answer 1

First, a correction:

 control_block_ptr->refs.fetch_sub(1, memory_order_acq_rel) == 0 

You mean == 1 . fetch_sub returns the value before the subtraction, not afterwards.

That having been cleared up:

Is it possible that we have a racing problem between the "if" and the "delete" below? what if we try to create a brand new smart_ptr obj in a different thread right right AFTER the "if" and BEFORE "delete"?

So, you're destroying a smart_ptr object. If control_block_ptr->refs is 1, then that means that the current smart_ptr is the only object which owns the control block, right? So what are you concerned about?

After all, some "brand new smart_ptr " will have its own "brand new" control_block_ptr and its own reference count. That will in no way interfere with the one being destroyed.

The only way there could be a problem is if there is a race between the destruction of a smart_ptr and the act of copying it. And by "it", I mean literally the same object ; not just any smart_ptr , but the same unique owner of this control block that is being destroyed.

See, if you had two smart_ptr objects sharing the same state, copying one while destroying the other is fine, because regardless of the order of those operations, everything works out. One of them will decrement the reference count; the other will increment it. But because the reference count started at 2, the reference count never hits 0.

But if if you're copying the same object you're destroying... well, that's just broken code. Note that while std::shared_ptr specifically states that updates to the reference count in the shared state are atomic and do not cause data races, multiple accesses to the same shared_ptr object from different threads are a data race (and thus undefined behavior). So long as at least one of the accesses is not a const operation; the copy is a const operation, but the destruction is not, so it applies.

The same will have to be true of your smart_ptr : if you attempt to copy the same object you're destroying, then bad things happen.

Answer 2

Generally (at least for boost and standard library smart pointers) smart pointers objects themselves are not designed to be threadsafe. Only the management/lifetime of the object that they point to is threadsafe. The smart_ptr object itself is not safe to use in multiple threads simultaneously, but it is safe to have multiple different smart_ptr objects referring to the same base data, that are all being used simultaneously.

In your example, the "brand new smart_ptr" that is being created in a different thread must be being copied from some existing smart_ptr.

If that existing smart_ptr is not the one being destructed, it will make sure that the if branch will never be taken in the destructor, since it will keep the object alive.

If that existing smart_ptr is the one that is being destructed in your example, then you have a problem, but this is because you are attempting to use a smart_ptr object that is in the middle of being destroyed. Even if the destructor was race free in this scenario, there would still be the possibility that the other thread would continue using the smart_ptr after it had been destoryed, which is always illegal in C++.

Answer 3

Simply put, no.

A race condition, that an end result dependent on a particular ordering of operations, is only possible on a reference count an operation can make an object that contributes to the count from one that doesn't , that is, when you have weak references .

Here what counts as a racing endpoint is whether or not the resource is released because the refcount (RC) reaches zero; the question "which exact operation, performed by which thread, makes the RC zero" is an interesting endpoint: the implicit assumption in the use of RC for managing ressources in a multithreading context is that any thread (which has the last owner) can release the resource.

By definition a RC is the sum of individual strictly positive contributions of each owner to the RC (which happen to be 1 as the RC is the number of owners but that isn't very important). In an abstract setting, the RC could also be formalized as the set of owners, and an integer would be an efficient representation of the information needed, because of the specifics of RC:

• each owner knows that it's in the set
• owners don't know each others
• each owner needs to increase the number by some amount (which is 1 by definition, but could be any strictly positive number) on being added to the set and decrease it by the same amount when it removes itself from the set

So you can imagine the number as essentially a list of owners, each being represented by a vertical line as when children learn numbers (3 = ||| ), and only an individual owner knows its own bar (you can either say all bars are the same or they have distinct colors). (The integers obviously are physically represented in binary.)

In setups where only owners exist (no operation can refer to a RC through a "weak reference") there are only two basic operations on the set of owners:

• duplicate an owner: make a new owner from an owner
• remove an owner

The duplication just adds a vertical bar. In a graphical display, you could even split a bar by erasing its middle, ending with two half bars. This is ownership being dissolved (as if you sold part of your shares of a traded corporation).

The removal operation erases the vertical bar that belong to the owner (of course in practice there are no identified bars, not bars at all and its a decrement operation of an integer represented in binary); if that operation removed that last bar then the removing thread is responsible for releasing the resource .

You can easily see that a zero RC corresponds to an empty set of bars, which happens after all owners have given up on owning. There is a race condition that determines the exact number of bars at any given time but that's a detail: what matters that each owner in each thread knows that he is an owner. It's essentially indifferent to the number of other owners. (If you were not indifferent you probably would have wanted unique ownership in the first place, to be able to alter the resource without impact on other users.)

That there is a race condition on the set implies that internal atomics (or a similar alternative) must be used, but owners shouldn't care in general. It would be catastrophic if a particular "bar" was accidentally erased in the representation, it would mean that an owner is not accounted for and it would be a zombie owner: it would believe it owns the resource but it wouldn't actually own anything. Atomic RMW (read modify write) operation guarantee that cannot happen: any atomic object modified exclusively by RMW operation cannot have lost modifications .

The very concept of ownership implies that it can't be created from nothing: you can only become the owner of something:

• by creating that thing
• or acquiring ownership (some) from someone who already has some

That's just common sense.

Because destruction of a share of ownership is irreversible, reaching zero owners is a terminating event; at that point, the RC is guaranteed to never be changed again, or to even be measured again. (So ownership of the RC representation is superposable to ownership to the resource itself.)

These properties make RC implementation of true ownership very simple. This is different when weak references, that is RC-only watcher , enter the picture: a RC measurement tool provides the guarantee that it can make a measurement on the RC at any point in the future, whether or not the managed user resource still has owner(s), whether or not the user resource still exists. With weak references a RC can be read as zero by an atomic operation, that is no vertical bar in the graphical representation of the set of owners. It means that the lifetime of the RC becomes distinct from the lifetime of the user resource: the RC itself becomes another managed resource (by internal RC).

Weak references allow the creation of owners without sharing existing ownership: a weak reference is an (unreliable) "option" on future ownership. Although weak references can only be created from real (ie strong) references, that conflicts with the general principles of ownership.

So only with weak references, RC can be durably zero , that is zero outside the small interval between the last decrease operation and the freeing of the RC itself. Using weak references means that user code must be designed to deal with the possibility of a zero RC, and that in MT code there can be a race between a thread giving up ownership as the last owner and another thread trying to recreate ownership from a weak reference.

In real life, the traditional cultural knowledge is free and can be replicated as much as you want. But for historical traditional knowledge known by extremely few people (like a family cooking recipe), you better make copies before the last person having that knowledge dies: there is a race between people dying with traditional knowledge and people acquiring and transmitting that knowledge. This is essentially the same as the weak reference/strong reference race issue.

So weak references can be a useful to model real world issues where an observer cannot forcibly keep a resource alive if external factor tear it down, but can observe the evolution of the resource while it exists. Promoting a weak reference to a strong one takes a snapshot of the liveliness of the resource at the instant the conversion is done, and is inherently racy.

Note that any meaningful use of many primitive is racy at some level : you use a mutex because you don't know which thread will need exclusive access to a resource first; if you knew the exact order of execution, you would serialize the threads and avoid the complexity of threading altogether. A race to get access to a resource is not a bug. Only when the correctness of a program execution depends on a particular order of events, there is a bug.

We know the destructor code below is supposed to release the control block if this is the last smart_ptr pointing to the resource being managed.

Yes and this is correct, wanted behavior when the useful lifetime of the RC ends when it reaches zero, that is when true ownership is implemented and weak references are not supported. That would not be correct for a Boost or standard shared_ptr which does support "weak" pointers aka non owning observers.

Although the race condition you mentioned in semantically impossible, there are issues here:

 ~smart_ptr() { if (control_block_ptr->refs.fetch_sub(1, memory_order_acq_rel) == 0) { delete control_block_ptr; } } 

As explained, the lifetime of the RC, when no pure observers (that are non owning and can see a zero RC) exist, is the same as the managed user resource. I don't see the release of the user resource here (it might be elsewhere).

Where is the user resource itself managed? Is it in the destructor of the *control_block_ptr object? Can you post a bit more code to have a complete picture?

Also you used a the post -decrement operation fetch_sub instead of the pre-decrement operation: "post" operations return the previous value then perform the operation. With a post operation the special interesting RC value you want to act upon, the value before the last owner stops being an owner, is 1, not 0 .

Answer 4

If the constructor is non-buggy, then it will see that the refcount is already zero, and thus the destruction process has started and is irreversible. So from the POV of other threads, the object is already destroyed when the refcount hits zero, even though delete hasn't actually deallocated the memory yet.

Plus, if a destructor brings the refcount to zero, it means there aren't any more shared_pointer objects to copy-construct from. (Unless you have a use-after-free bug for the object itself, not the control block. In which case you're using it wrong: normally you don't make references to shared_ptr objects.).

So if I'm remembering correctly how shared_ptr works, this problem doesn't exist for it. (And thus why the refcount can be kept in the object that will be deallocated. In a non-garbage-collected environment, the reclaim problem is hard because you can't free memory that some other thread might still have a pointer to. See user-space vs. kernel RCU implementations for examples of the challenges. A lockless linked-list queue might always return nodes to a dedicated free-list for objects of that type, not a general pool that could let them be reused as something else or unmapped with a system call.)

---

But in the general case of refcounted objects, seeing refcount=0 means destruction has passed the point of no return , and your attempt to acquire a new reference to it has failed. (ie happened after the destruction, in the global order established by the atomic counter).

This "seeing" would be in the return value of a fetch_add(+1) , of course.

---

Anyway, this design for attempts to acquire a new reference is what makes it safe to proceed to deallocation after your decrement made the refcount zero.