Development with a Dot

Introduction This is the second in a series of posts on .NET synchronisation: In-process synchronisation Out-of-process synchronisation on the same machine (this post) Distributed synchronisation This time I'm going to talk about using the synchronisation APIs I described on the first post , dedicated to in-process synchronisation, but in out-of-process context, meaning, to synchronise different processes, not threads. This can be achieved out of the box with three synchronisation objects: Mutex Semaphore EventWaitHandle  (remember, parent class of AutoResetEvent and ManualResetEvent ) These objects follow the same pattern: open (fails if doesn't exist) or try to open an existing object by its name.  For a synchronisation object to be available system-wide it needs a name and can have fine-grained permissions on Windows systems. I will cover permissions more to the end of this post. I will also be covering an additional technique that can also be used for synchronisation: s h...

Introduction This is the first in a series of posts on .NET synchronisation. I will cover: In-process synchronisation (this post) Out-of-process synchronisation on the same machine Distributed synchronisation In .NET, in-process synchronisation mechanisms are used to restrict access to shared resources and manage concurrency in multi-threaded applications. The mechanisms I'm going to present on this post can be used only for in-proc code, for synchronising threads, meaning, they cannot be used to synchronise multiple processes, on the same or on different machines - I will write more posts on these subjects and link them here. Here I will be using the terms "locking" and "synchronising on" interchangeably, to mean the same thing. I won't go into too much theory, but thread synchronisation exists for preventing: Race conditions: two threads trying to modify the same data simultaneously Data corruption: data shared by two or more threads becomes inconsistent ...