5 ms·

I'd like some more explanation of why the author thinks it's better to use a lock statement than an Interlocked method most of the time. This is really just fu

by mathw 10y ago

I'd like some more explanation of why the author thinks it's better to use a lock statement than an Interlocked method most of the time. 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.

gwbas1c 10y ago
Yeah, I tend to prefer various forms of Interlocked to avoid deadlocks that happen 0.01% of the time.
achr2 10y ago
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...
- Sharlin 10y ago
  > 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.
  - TillE 10y ago
    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.
- blahfuk 10y ago
  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#.
chaostheory 10y ago
> 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

by mathw 10y ago

gwbas1c 10y ago

Yeah, I tend to prefer various forms of Interlocked to avoid deadlocks that happen 0.01% of the time.

achr2 10y ago

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...

Sharlin 10y ago
> 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.
- TillE 10y ago
  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.
blahfuk 10y ago
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#.

chaostheory 10y ago

> 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