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_ptrper 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_ptrfrom multiple threads. This is still similarly safe.
- Copying / deleting thread-local shared_ptrs 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_ptrs 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_ptracross 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