[vtk-developers] Change in VTK[master]: Added support for atomic integers.

[Sean McBride]

On Tue, 20 Aug 2013 12:56:07 -0400, Berk Geveci said:

>Keep in mind that we want to support lots of platforms from various
>desktops to supercomputers to potentially embedded systems.

All the more reason to use std::atomic, no?  It's new, so isn't widely supported yet, but going forward it seems preferable.  Newest gcc and clang both claim to fully support C++11 now.

>> Was the OSAtomicIncrement32/64Barrier() call deliberately weakened to
>> OSAtomicIncrement32/64()?  The Windows InterlockIncrement() is documented
>to use a
>> memory barrier, and VTK on OS X did before, so...
>
>It was deliberate change based on the documentation, which says:
>
> *SNIP*
>
>What we are doing in vtkTimeStamp falls into "simply incrementing a global
>counter", which justifies using a much faster implementation in my opinion.
>What do you think? We'll probably have to revisit what AtomicInts do under
>covers if people start using them for other purposes than counters.

Well, I am not a multithreading expert, but I know enough to know that it's playing with fire. :)  The docs you  quote do say "Most code should use the barrier functions to ensure that memory shared between threads is properly synchronized".

If you think the weaker non-barrier version is sufficient, why on Windows do you use InterlockedIncrement() and not InterlockedIncrementNoFence()?

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada