boost threads - is scoped_ptr::reset() an atomic operation?

Question

This is the first time I'm using threads, and I'm doing it with boost. The situation is that I have a big array of 3d polygon meshes for which I build an octree (one tree per mesh). I'd like to execute the build process in parallel, and immediately go to openGL display loop - without waiting for the builds to complete. (The object simply won't display anything until its octre is complete).

I use boost::scoped_ptr::reset() to attach octree data to my objects. Can I consider reset() method to be atomic operation in threaded execution? If not what should I look after ?

Below is the pseudo code depicting what I'm doing. The actual code works as expected, but I experience occasional crashes (may be related to smth else.)

class BigData
{
private:
    boost::scoped_ptr<float*> p_data_;

public:
    void Compute() // this will run in threads
    {
        float* p_temp = new float [1000];
        DoComputation(p_temp);
        p_data_.reset(p_temp); // atomic ?
    }
    void operator()() {Compute();}

    void Display() // do nothing if p_data_ is not ready
    {
        if(p_data_)
            DoDisplay();
    }
}


int main()
{
    std::vector<BigData>    objects_arr(1000);

    // run Compute() in threads
    for(int i=0; i<objects_arr.size(); ++i)
        boost::thread comp_thread( objects_arr[i] );

    // immediately go to display
    while(true)
    {
        for(int i=0; i<objects_arr.size(); ++i)
            objects_arr[i].Display();
    }

}

1) scoped_ptr have no relation with thread synchronization and btw they aren't atomic operations. and 2) you're using scoped_ptr in very weird way .... — alexbuisson, Feb 27 '14 at 21:31

score 1 · Accepted Answer · edited May 23 '17 at 12:14

1

Nope. This isn't really an issue with boost::scoped_ptr so much as a problem with pointer assignment in general.

Is pointer assignment atomic in C++?

edited May 23 '17 at 12:14

Community

1
1

answered Feb 27 '14 at 21:58

QuestionC

10,006
4
26
44

alexbuisson · Answer 2 · 2014-02-27T22:01:31.460

Class like scoped_array, scoped_ptr, shared_ptr are just different implementation of the RIIA pattern and aren't thread-safe. so if you want use those class in a multithread context where data race can occur you must protect those variable using a synchronization primitive by yourself

when defining a scoped_ptr you don't have to mentioned that it will store ptr. it's by design, so we can just write :

     boost::scoped_ptr<float> p_data_;

and looking at your code I think that you wanted to write:

    void Compute() // this will run in threads
{
    boost::scoped_array<float> p_data(new float [1000]);
    DoComputation(p_data.get());
    // no need to call reset ... 
}

I replace scoped_array with scoped_array because if you allocate something with new [] you must release it with delete [] and scoped_array do that!

we can also remove the call to reset because the RIIA pattern provided by the scoped_ .. class provide that behavior by design. when the identifier goes out of the scope resources are released.

boost threads - is scoped_ptr::reset() an atomic operation?

2 Answers2