[Insight-developers] itkTimeStamp Test Failures Mistery

[Tom Vercauteren]

Hi Sean,

Thanks for the feedback.

About the performance. In some scenarios
(e.g.http://www.itk.org/pipermail/insight-users/2008-March/025081.html),
even on multicore machines,  the non-optimized version leads to
multithreaded code being slower that non-multithreaded code. So the
performance impact can be huge.

I agree that on a more typical setting, the impact will not be as
large. I remember that in one of my applications, I first used a
workaraound to avoid the timestamp mutex lock. Then, I applied the
atomic increment patch and got something like a 10 or 15% speedup on
an dual quad-core computer.

Apparently you also experienced a similar bottleneck which is why you
committed the optimization for mac, right?
http://www.itk.org/pipermail/insight-users/2008-March/025082.html


Concerning the problem, considering that the integer assignment is not
guaranteed to be atomic, we could either:
- do nothing, it would be up to the user to ensure that no two calls
to modified are done simultaneously on the same object
- make sure that we at least use atomic assignments, this ensure that
the modified time is meaningful
- use a local mutex lock around the optimized version, this ensure
full thread-safety

The second option needs some more work since atomic assignment is
apparently not easy to get. Here is what I found:
- On windows there's InterlockedExchange
http://msdn.microsoft.com/en-us/library/ms683590(VS.85).aspx
- With gcc and icc there might be __sync_lock_test_and_set but the
documentation is a bit scary
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
- On mac it is not so clear. Could we use
OSAtomicCompareAndSwapPtrBarrier?
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/atomic.3.html#//apple_ref/doc/man/3/atomic
- the volatile keyword is sometimes considered as a cheap (but wrong?)
version for having a native type being atomic...


Thoughts?


By the way, from apple's doc
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/atomic.3.html#//apple_ref/doc/man/3/atomic
we can see that "if you are simply incrementing a global counter, then
it is safe and potentially much faster to use OSAtomicIncrement32()
[w.r.t. OSAtomicIncrement32Barrier()]". This means we could change the
current call to OSAtomicIncrement32Barrier (resp 64) by a call to
OSAtomicIncrement32 (resp 64).

Tom



On Thu, Feb 19, 2009 at 20:40, Sean McBride <sean at rogue-research.com> wrote:
> On 2/19/09 8:06 PM, Tom Vercauteren said:
>
>>When several threads assign the same integer variable at the same
>>time, is it possible that the value of the integer be corrupted or can
>>we safely assume that the value of the integer will be one of those
>>trying to be assigned by the threads?
>
> I don't think C/C++ make any such guarantee.  However, I believe 'in the
> real world', it's a pretty safe assumption.  This was actually discussed
> recently on another list:
>
> <http://lists.apple.com/archives/objc-language/2009/Feb/msg00028.html>
>
> "Ordinary assignment (of pointer-aligned pointer-size values) is a
> single instruction on any practical CPU architecture. That assignment is
> atomic with respect to simultaneous read (pointer-size pointer- aligned)
> of that same memory location. That is, the reader will always get either
> the old value or the new value, never something half-and- half or random."
>
>>If we go for thread-safe, we need to modify the TimeStamp
>>optimization.
>
> How different is performance using the mutex instead of the 'optimised'
> version?  ie: do we need the optimised version at all?
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>