Locking based on parameters

Suppose I have this method:

void Foo(int bar)
{
    // do stuff
}

Here is the behavior I want Foo to have:

1. If thread 1 calls Foo(1) and thr开发者_高级运维ead 2 calls Foo(2), both threads can run concurrently.

2. If thread 1 calls Foo(1) and thread 2 calls Foo(1), both threads cannot run concurrently.

Is there a good, standard way in .net to specify this type of behavior? I have a solution that uses a dictionary of objects to lock on, but that feels kind of messy.

---

Use a dictionary that provides different lock objects for the different arguments. Set up the dictionary when you instantiate the underlying object (or statically, if applicable):

var locks = new Dictionary<int, object>() {
    {1, new Object()},
    {2, new Object()},
    …
};

And then use it inside your method:

void Foo(int bar) {
    lock (locks[bar]) {
        …
    }
}

I wouldn’t say that this solution is messy, on the contrary: providing a fine lock granularity is commendable and since locks on value types don’t work in .NET, having a mapping is the obvious solution.

Be careful though: the above only works as long as the dictionary isn’t concurrently modified and read. It is therefore best to treat the dictionary as read-only after its set-up.

---

Bottom line: you can't lock on value types.

The dictionary you're using is the best approach I can think of. It's kludgey, but it works.

Personally, I'd pursue an architectural solution that makes the locking unnecessary, but I don't know enough about your system to give you pointers there.

---

Using Dictionary is not enough, you should use "ConcurrentDictionary" or implement a data structure that supports multi-thread access.

---

Creating a Dictionary<> so that you can lock on a value seems overkill to me. I got this working using a string. There are people (e.g. Jon Skeet) who do not like this approach (and for valid reasons - see this post: Is it OK to use a string as a lock object?)

But I have a way to mitigate for those concerns: intern the string on the fly and combine it with an unique identifier.

// you should insert your own guid here
string lockIdentifier = "a8ef3042-e866-4667-8673-6e2268d5ab8e";
public void Foo(int bar)
{
    lock (string.Intern(string.Format("{0}-{1}", lockIdentifier, bar)))
    {
        // do stuff
    }
}

What happens is that distinct values are stored in a string intern pool (which crosses AppDomain boundaries). Adding lockIdentifier to the string ensures that the string won't conflict with interned strings used in other applications, meaning the lock will only take effect in your own application.

So the intern pool will return a reference to an interned string - this is ok to lock on.