Use of auto and atomic in threadExample

Hi,
I’m working thru the threadExample; its my first time with ofThread.

I noticed that all of the local variables in threadedFunction() are auto, and that atomic is included in the header file threadedObject.h. So, I’m thinking that the compiler will construct atomic versions of variables when auto is used. Does anyone know if this is correct? And if so, are atomic variables required, or good practice? Thanks for the help! The code from threadedObject.h is below, minus the comments:

    void threadedFunction(){
        while(isThreadRunning()){
			threadFrameNum++;

            std::unique_lock<std::mutex> lock(mutex);

            auto t = ofGetElapsedTimef();
            for(auto line: pixels.getLines()){
                auto x = 0;
                for(auto pixel: line.getPixels()){
                    auto ux = x/float(pixels.getWidth());
                    auto uy = line.getLineNum()/float(pixels.getHeight());
                    pixel[0] = ofNoise(ux, uy, t);
                    x++;
                }
            }

            condition.wait(lock);
        }
    }

Hi,
auto has nothing to do with atomic.
auto just will let the compiler to figure out the type of the variable. It just saves you time, instead of having to go and find what type is a function returning you can let the compiler to figure it out.

It seems like you can get rid or #include <atomic> in threadedObject.h and it will still compile.
atomic variables are a completely different thing. These are variable that can only be modified or read by a single thread at a time, which is used for sincronizing data between threads. It is a much simpler way than with mutex locks, although it might not work on all possible scenarios. And yes, if you are able to use atomic variables it is recomended (and even faster (I read that somewhere I can not recall)) over using mutexes.

Hey @roymacdonald thanks for a quick reply! I think the #include atomic is what threw me off and caused the confusion. I spent some time with typeid().name() and std::cout and the auto types. The ones I checked were not std::atomic types. Moreover, with more goofing around, I couldn’t manage to create and then use atomic versions of non-trivial types (like ofPixels), but I could with trivial types (like float).

Hi, that’s why I was saying that are cases in which some types will not work with atomic. Any basic data type will work but for more complex classes these need to comply with several rules.
If you want to pass around pixels from one thread to another one I recommend you to use ofThreadedChannel. There is an example for these in examples/threads/ folder.