Re:Common Multithreading Mistakes in C# – Unsafe Assumptions
by achr2 on Wednesday February 22, 2017 @09:37AM
(#13705767)
I agree about the use of Interlocked. Obviously if you already need a lock around additional code, there is no need to use Interlocked, but for any single statements where Interlocked is available, it is a simple performance gain. That said I have seen several incorrect and unnecessary `CompareExchange` usages that could have been avoided with a simple lock...
[ Parent
| on HN ]
Re:Common Multithreading Mistakes in C# – Unsafe Assumptions
by Sharlin on Wednesday February 22, 2017 @10:04AM
(#13705984)
> That said I have seen several incorrect and unnecessary `CompareExchange` usages that could have been avoided with a simple lock...
This is, obviously, the answer to the GP's question.
Re:Common Multithreading Mistakes in C# – Unsafe Assumptions
by TillE on Wednesday February 22, 2017 @01:23PM
(#13707754)
That's no reason for avoiding atomics in simple use cases. "Use locks and then profile" is fairly bad advice. Forget the profiler and always use atomics in simple situations where you know exactly how they work. Just don't try anything complicated with them.
Re:Common Multithreading Mistakes in C# – Unsafe Assumptions
by blahfuk on Wednesday February 22, 2017 @03:05PM
(#13708706)
However, interlocked is really the only way to create (most) lock-free data structures. Fortunately, there are a few libraries available for that now, but it wasn't always that way in C#.