Is it safe to use a shared_ptr
inside an OpenMP parallel block in any way? A shared_ptr
maintains atomicity of reference count through the use of an atomic and in general it is my understanding that we should not be mixing C++11 multi-threading mechanisms with OpenMP. So by definition it seems to me that accessing a shared_ptr anywhere inside an pragma omp
block (even for simple const read operations) could cause problems. Or this is not the case?
Asked
Active
Viewed 730 times
2

Zulan
- 21,896
- 6
- 49
- 109

astrophobia
- 839
- 6
- 13
1 Answers
2
Your analysis is quite correct. First, take a look at this question about OpenMP and std::atomic
. Note that, std::shared_ptr
isn't necessarily implemented using atomics. Also this applies to the shared control block, which is modified with during copy operations. There are a couple of cases:
- Calling
get
/operator->
/operator*
with oneshared_ptr
per thread that points to the same object. Only performing read-only operations on the target object. This is as safe as it gets given the specification-gap between C++11 and OpenMP. No control-block operations are performed. I would argue that this is not different from using a raw pointer. - Calling
get
/operator->
/operator*
on one sharedshared_ptr
from multiple threads. This is still similarly safe. - Copying / deleting thread-local
shared_ptr
s that points to different objects across multiple threads. This should still be as safe as it gets as there is no shared date. - Copying / deleting thread-local
shared_ptr
s that point to the same object from multiple threads. Now we know this involves shared control date, but it is safe according to the C++ standard. The argument forstd::atomic
/ OpenMP applies. It is practically safe but not very well defined. - Modifying (
reset
) a thread-sharedshared_ptr
across mutiple threads. This is unsafe.atomic<shared_ptr>
can be used here, but then the same argument applies.
I would make one more distinction. If you consider using std::atomic
with OpenMP there is the alternative of using the OpenMP-idiomatic pragma omp atomic
- there is no OpenMP equivalent to shared_ptr
. So short of implementing your own shared_ptr
on top of omp atomic
you don't really have a choice.

Zulan
- 21,896
- 6
- 49
- 109