Static Methods and Locking

6. February 2008 05:42

Recently, I was reviewing some code for a new application and noticed several static methods that were locking to safeguard against concurrently executing threads.  However, the majority of these static methods did not involve any static data.  So, it seemed like a good opportunity to post a reminder that it isn't always necessary to lock a method simply because it is static. 

Recall that static methods belong to the class rather than instances of the class.  As such, any concurrently executing threads will invoke the same static method.  Obviously, it becomes a possibility that a collision could occur between concurrent threads.  However, this is only the case when the static method uses static state.  As long as the static method is stateless, the static method will operate upon the stack of each thread independently of one another.

Consider the following example:

public static int StatelessAdd(int value1, int value2)
{
    return value1 + value2;
}

In this method, there is no state that has to be managed between invocations.  Each time the method is executed, the executing thread will supply the parameters from its stack.  The implementation is simple and doesn't utilize any static state that could be concurrently accessed by multiple threads.  This situation doesn't merit any need for locking.

Now, consider another example:

public static int StatefulAdd(int value1, int value2)
{
    _counter++;
    return value1 + value2;
}

In this method, there is a static member variable used to track the number of times the static method has been invoked.  This scenario introduces static state that is modified during the operation.  As such, it is possible that a collision could occur between concurrently executing threads.  This situation does merit the need for locking.  

Here is a revised example:

public static int StatefulAdd(int value1, int value2)
{
    lock (_syncLock)
    {
        _counter++;
    }

    return value1 + value2;
}

Note that the section of code that modifies the static state has been enclosed with a lock statement for thread safety.  Obviously, this is a contrived example, but it sufficiently conveys the concept of when locking is necessary.  The key thing to remember is locking should only be used when absolutely necessary.  Otherwise, you are unnecessarily introducing points of contention that contribute to performance degradation.

Comments are closed

About Me

I'm a passionate software developer and advocate of the Microsoft .NET platform.  In my opinion, software development is a craft that necessitates a conscious effort to continually improve your skills rather than falling into the trap of complacency.  I was also awarded as a Microsoft MVP in Connected Systems in 2008, 2009, and 2010.


Can’t code withoutThe best C# & VB.NET refactoring plugin for Visual Studio
Follow jeff_barnes on Twitter

View Jeff Barnes's profile on LinkedIn

 

Shared Items

Disclaimer

Anything you read or see on this site is solely based on my own thoughts.  The material on this site does not necessarily reflect the views of my employer or anyone else.  In other words, I don't speak for anyone other than myself.  So, don't assume I am the official spokesperson for anyone.