Re:Common Multithreading Mistakes in C# – Unsafe Assumptions
by chaostheory on Wednesday February 22, 2017 @02:39PM
(#13708505)
> Something which is sadly in short supply in some people's skill sets
Things may have changed, but when I last looked there are very few books on multithreading, especially when it comes to a particular language. A lot of it seems to just be learned on the job using reference docs
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...
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#.
This is really just fundamental concurrency stuff though. Something which is sadly in short supply in some people's skill sets, but then I guess not everyone spent four years working on massively multithreaded C++ software early in their career like I did.
I'd really prefer it if C# made you share memory explicitly - default shared memory concurrency is just asking for trouble, in this and many other languages, because you have to do extra to do things right, rather than extra to do things wrong.