.NET Synchronisation APIs - Part 2 - Out-of-Process Synchronisation

Introduction

This is the second in a series of posts on .NET 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:

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: shared files.

Mutex

Why would we have a cross-process Mutex? Well, imagine for example that you want an application to only have at most one executing instance; you can achieve that with a mutex.

Here is a simple example using OpenExisting:
Mutex? mutex = null;
var mutexName = "Global\\My Application";

try
{
    mutex = Mutex.OpenExisting(mutexName);

    if (!mutex.WaitOne(TimeSpan.FromSeconds(0))
    {
        //mutex is currently locked, meaning, another instance of the app is running
    }
}
catch (WaitHandleCannotBeOpenedException)
{
    //does not exist
}
catch (UnauthorizedAccessException ex)
{
    //no permission to access it
}

Semaphore

For Semaphore, it is very mich the same as for Mutex, except multiple processes can get inside. Think, for example, of a number of worker processes you want to allow in. Here is an example using TryOpenExisting and WaitOne with a timeout:

Semaphore? semaphore = null;
var semaphoreName = "FooBar";

if (Semaphore.TryOpenExisting(semaphoreName, out semaphore))
{
    if (!semaphore.WaitOne(TimeSpan.FromSeconds(0))
    {
        //semaphore is currently locked, need to wait until someone releases it
    }
}
else
{
    semaphore = new Semaphore(0, 3, semaphoreName);
}

EventWaitHandle

You may recall from the previous post that EventWaitHandle is the parent class of both AutoResetEvent and ManualResetEvent. When we ask for a named event object, we do not know it's type, it can either be an AutoResetEvent or a ManualResetEvent, and we should not be bothered with that.

EventWaitHandle? evt = null;
var eventName = "FooBar";

if (EventWaitHandle.TryOpenExisting(eventName, out evt))
{
    if (!evt.WaitOne(TimeSpan.FromSeconds(0))
    {
        //event is currently locked, need to wait until someone signals it
    }
}

As you can see, EventWaitHandle, Semaphore, and Mutex all follow the same pattern: OpenExisting/TryOpenExisting or create with a name.

Shared Files

Using a shared file for synchronising accross processes (even on different machines, if the file is located in shared storage) is yet another option. 

File.Open lets us open an existing file with different access and share modes. If we use FileShare.None, then the file is either open with exclusive access or any attempt to open it fails, until the file is closed by the opening process:

FileStream file = null;
var name = "\\file.lock";

try
{
    file = File.Open(name, FileMode.Create, FileAccess.ReadWrite, FileShare.None);

    //perform critical operation

    file.Dispose(); //release lock
}
catch
{
    //file could not be open exclusively
}

As you can see, pretty straightforward, but with one caveat: the file stays created, even if a crash occurs, so you must be aware of stale files! Files can of course also be created with fine-grained security (access control lists) but I will not cover it here.

Sharing Data

What if you want to share data between the processes that you are synchronising? There are a couple options like:

I won't dwell on this, but I once wrote a post on IPC on the same machine, if you're curious, you can have a look, even though it is somewhat outdated.

Security

Namespace and Scope

EventWaitHandle, Semaphore and Mutex can take a NamedWaitHandleOptions parameter on their constructors which offers two boolean properties:

This defines the scope for the object. Alternatively, we can control names passed to EventWaitHandle, Semaphore and Mutex's constructors; these must fall into two possible namespaces:

  • Local\<name>: visible only within the current session (normal desktop app behaviour)
  • Global\<name>: visible across all sessions 

As an alternative to the methods that accept a NamedWaitHandleOptions parameter to set the scope, methods that only take a name parameter can prefix it with "Global\" or "Local\" to specify a namespace. When the Global namespace is specified, the synchronisation object can be shared with any processes on the system; when Local is specified (the default when no namespace is specified), the synchronisation object can be shared with processes in the same session.

Access Control Lists

A different option is to control who can use your synchronisation object using Access Control Lists (ACLs): an ACL contains the intended users/groups (security identifiers, or SIDs) for the synchronisation object, rights/permissions on the it (modify, delete, full control, etc), and the access control type (access, deny). This is really only valid for Windows. To use ACLs, this is what we need to do:

var allowedUser = "...";
// can be in the following formats:
// "DOMAIN\User" -> domain user/group
// ".\LocalUser" -> local user/group
// "S-1-5-21-...." -> SID that describes any user/group

// Windows: get the security id (SID) for a named user
var userSid = (SecurityIdentifier) new NTAccount(allowedUser)
    .Translate(typeof(SecurityIdentifier));

var security = new SemaphoreSecurity();
// explicitly allow this user
security.AddAccessRule(new SemaphoreAccessRule(userSid, SemaphoreRights.Synchronize | SemaphoreRights.Modify, AccessControlType.Allow));

// often wise to also allow LocalSystem (for services, OS components), optional using WellKnownSidType.LocalSystemSid SID:
security.AddAccessRule(new SemaphoreAccessRule(new SecurityIdentifier(WellKnownSidType.LocalSystemSid, null), SemaphoreRights.FullControl, AccessControlType.Allow));

ver semaphore = new Semaphore(1, 3, "Global\\semaphore_name");
semaphore.SetAccessControl(security);

By default, when we apply security, all users/groups are denied, so we need to explicitly allow the users/groups we want to allow, and what is their level of access. The former example is for Semaphore but it is essentially the same for Mutex and EventWaitHandle. Here are the types involved:

Synchronisation Object Access Rules Rules Gathering ACL Extensions Rights
Semaphore  SemaphoreAccessRule SemaphoreSecurity SemaphoreAcl SemaphoreRights
Mutex  MutexAccessRule MutexSecurity MutexAcl MutexRights 
EventWaitHandle EventWaitHandleAccessRule EventWaitHandleSecurity EventWaitHandleAcl  EventWaitHandleRights

And this is a brief explanation, somewhat simplified:

  • Rules Gathering: collects all the access rules for a synchronisation object. It's a xxxSecurity class
  • Access Rules: consists of a security identifier (SID) and a set of rights with an access control type. A xxxAccessRule class
  • ACL Extensions: extension methods for working (creating, opening existing) with synchronisation objects and security (Create, OpenExisting, TryOpenExisting). Exist on a xxxAcl class
  • Rights: the actual rights (permissions) on the target object for a given SID (Modify, Delete, ReadPermissions, ChangePermissions, TakeOwnership, Synchronize, and FullControl). Exist as xxxRights enumerations
  • Access Control Type: one of Allow, Deny values from the AccessControlType enumeration, for all synchronisation objects

The actual attachment of security to an object is achieved through the SetAccessControl/GetAccessControl extension methods from the ThreadingAclExtensions class, that apply to both Semaphore, Mutex, and EventWaitHandle. This requires the System.Threading.AccessControl NuGet package.

Conclusion
Named synchronisation objects are an essential tool for doing any advanced desktop (non-web) development, such as Windows Forms, WPF, Maui, or even console or Windows Services apps. You should pick the one that best suits your needs, and here is a simple guide for selecting the right synchronisation object:
  • When you need do synchronise on the same machine, just need mutual exclusion: named Mutex
  • Allow up to N concurrent holders: named Semaphore
  • Just need “wake up/signal” between processes: named EventWaitHandle; it can release exactly one waiting process (AutoResetEvent) or all (ManualResetEvent)
  • Access across shared storage, survive crashes (beware of stale locks!): shared files
Don't forget that fine-grained security only works on Windows.

































Location:
Coimbra, Portugal
















Comments











Post a Comment



















Popular posts from this blog









C# Magical Syntax





















Introduction  This post is an update to an old one  on my  old blog  and it was inspired by my latest posts on C# versus Java . You may not have realized that some of the patterns that you’ve been using for ages in your C# programs are based on conventions, rather than on a specific API. What I mean by this is, some constructs in C# are based on some magical methods with well-defined names which are not defined in any base class or interface, but yet just work. Let’s see what they are.  Enumerating Collections You are probably used to iterating through collections using the foreach  statement. If you are, you may know that foreach actually wraps a call to a method called GetEnumerator , like the one that is defined by the IEnumerable  and IEnumerable<T>  interfaces. Thus, you might think, the magic occurs because the collection implements one or the two, but you would be wrong: it turns out that in order to iterate through a class using foreach all it takes is that the c...








Read more










.NET 10 Validation





















Note: this is an update to my original post .  Introduction  I wrote about  entity validation  in the past, the reason I'm coming back to it is that there are some changes in .NET 10, related to validation. Let's cover the original validation API and then explain what has changed. .NET Validation Validation is implemented in the System.ComponentModel.DataAnnotations  namespace. I'll describe it first and then move to the small changes in .NET 10. .NET has featured a way to validate classes and their properties for a long time, the API is called  Data Annotations Validation , and it integrates nicely with ASP.NET Core MVC and other frameworks (not Entity Framework Core, as  I've talked recently , nor ASP.NET Core Minimal APIs ). It is essentially, but not just, based on a set of attributes, one interface, and a class that performs validations on a target class and its properties, from the validation attributes it contain.  The base class for attribute validation is ca...








Read more










Modern Mapping with EF Core




















Image







Introduction In EF Core (as in most O/RMs) we can map and store multiple things:       Objects that hold a single value, like int , string , bool , float , Guid , DateTime , TimeSpan , Uri , etc. These are (somewhat wrongly) called primitive types  and are always included inside some container, like the following Objects that hold multiple single values and which have an identity, for example, Customer , Product , Order . These are called entity types  and they must have an identity that makes them unique amongst all the other objects of the same type Objects that are structured to hold multiple values, but have no identity, such as Address , Coordinate . These are called value types  and are merely a collection of (possibly related) properties We can also have collections of the previous things   There's more to it, of course, for example, it is even possible to represent  inheritance of entities , of which I talked about before , In this post I am going to cover so...








Read more