In the post about Basic thread safety in .Net we looked at techniques to avoid state corruption in asynchronous code.

In this post I will briefly show how you can utilize an Immutable state object for a very brief lock so you can access immutable data to ease your synchronization of your algorithms. The source code for this can be found here.

What this post will cover

  • ImmutableState object technique

What this post will not cover

  • The lock statement
  • What are mutable shared state issues

The general idea is to create an object, that encapsulates the state changes you want to apply and then create a new instance of it for each assignment, so that multistage transition can be handled by a single lock statement and assignment. We will look at a general example first and then how this can be abstracted for a more generic approach.

In the example I want to achieve a change to the fields of count and name simultaneously:

Now this is not a terribly good example, yet I think it gets the point across. To make those two statements into a single assignment operation we create an immutable state object:

Which we then use in the following class:

You can see, that there are locks only for the briefest moment, when you assign the readable object or assign the new Values.

This is not optimal though, because we use Public fields, and I want to create a more generic approach to it.  Public fields should be avoided, because you create a direct dependency and if you want to apply some logic to those fields in the future, you will most likely break the calling code.

So with the basic idea in mind we now create the following:

(this can be extended with as much type parameters as needed)

Usage is similar as above:

This can all be extended by applying Design patterns like Flyweight or object pooling to make the creation of the ImmutableState object much more efficient.

Summary

In this post I introduced you briefly to the idea behind the use of immutable objects for very short locks in a concurrent environment.

We looked at a plain approach and a more abstract one.

Leave a Reply