Reddit reviews Concurrent Programming on Windows

Most of what he says carries over to the .NET world with minor changes. And vice-versa - Joe Duffy's Concurrent Programming on Windows addresses some of the same things, even though it's really a Windows / .NET book.

threads are threads. The names of the functions we call change from platform to platform but the basic synchronization problems are the same everywhere.

One more plug: Allan Downey's free Little book of Semaphores will blow your mind if you're interested in really learning threads.

> You might adopt new things, but you're not adopting new ideas.

Bad ideas? No.

> Even Visual Studio doesn't work that way anymore and it's moving to more processes,

Yes, that's why the VS 2015 performance is much better than VS 2017 on the same hardware.

> For a dozen reasons, including security, performance

Can you elaborate how the split to multiple processes improves the performance? To create a new process is very expensive operation, compared to a new thread. The same with sharing data across processes versus threads. There is no benefit.

Process isolation can "resolve" poor code quality when a buggy code is more isolated. Again, it isn't any improvement, just a poor fix of having more incompetent developers on the board :-/

> When you're using synchronisation primitives you're doing message passing via shared state, and every time you hit one your code becomes synchronous.

No, you don't understand basic things. Recommended reading Concurrent Programming on Windows

If you want to learn it the right way, read this book. I warn you, it is deeply technical. But there is no better source.

https://www.amazon.com/Concurrent-Programming-Windows-Joe-Duffy/dp/032143482X

Now, all that said, there are various synchronization primitives that can be used, and there also some generic rules that you should always try to follow:

1. When using thread-affine locking primitives (such as a Mutex or a CLR lock), all operations inside of the lock should occur quickly.
   
2. In general, locks should be read-only - they should not change between accesses, or they may break synchronization
   
3. Many readers can safely access a data structure at the same time without risk, provided that those readers do not modify the data structure itself in any way (our hypothetical queue did not support this, because Dequeue did modify the data structure).
   
4. Others. You can spend years and years researching this.
   
   Primitives:
   
   
5. CLR locks (see the C# lock keyword)
   
6. Mutexes (thread-affine)
   
7. Semaphores (generally not thread-affine)
   
8. Reader/Writer locks (thread-affine, uses per-thread state)
   
9. Manual/Auto Reset Events (not thread-affine)
   
10. The CountdownEvent class (on .NET, can't recall if this is thread-affine or not)
    
    Anyway, this is probably the most detailed response I've ever typed to anything on the internet, so... I'll leave you with some recommendations.
    
    I think Jared Parsons summarizes the problems pretty well here and here.
    
    You can also have a look at Joe Duffy's blog. I'd also highly recommend his book Concurrent Programming on Windows. He discusses general operating systems concepts, some of which are specific to Windows, concurrent programming in C# and C++, and various other details... Really great read.