Add mutex to setEpsilon

[dschwen]

Closes #4111

Thanks @lindsayad for pointing me to thread_local

[roystgnr]

This scares me a bit. If I try to set epsilon to a new value while I'm in a non-threaded section of code, and then I enter into threads, what happens? My first guess would be "if new threads are being forked then they inherit the new value, but if we're using an underlying thread pool then only one of the threads in the pool has the new value", and if that's the case then that would be horrifying.

If there's already a setter function and we're only ever using that, could we just add a lock in the setter instead?

[lindsayad]

excellent point

[moosebuild]

Job Coverage, step Generate coverage on a7490b9 wanted to post the following:

Coverage

Coverage did not change

Full coverage report

This comment will be updated on new commits.

[dschwen]

We'll my first commit just makes epsilon atomic. That seems like the easiest way.

[lindsayad]

Push it

Oops jk it's not building :laugh:

[dschwen]

arithmetic operators aren’t overloaded for std::atomic types.

😭

meaning we'd have to add a crapton of .load().

[dschwen]

This scares me a bit. If I try to set epsilon to a new value while I'm in a non-threaded section of code, and then I enter into threads, what happens? My first guess would be "if new threads are being forked then they inherit the new value, but if we're using an underlying thread pool then only one of the threads in the pool has the new value", and if that's the case then that would be horrifying.

The right answer would be to set epsilon in the thread you expect it to be used (which is what we do in MOOSE). thread_local would be the smallest possible change to fix the underlying issue, and probably the best performing...

[roystgnr]

Looks good to me now; we'll merge in a day or so unless John has any complaint.

[jwpeterson]

My only question was whether making the std::mutex itself static creates another kind of race condition, but that appears to be safe to do.

[dschwen]

My only question was whether making the std::mutex itself static creates another kind of race condition, but that appears to be safe to do.

Love the first reply: