We Keep Coding

Lock around dictionary access in a WPF application

I'm working on an old and large WPF application. The customer reported a bug, which they were able to reproduce, but I can't. There is a class in the application that looks like this:
public static class PermissionProvider
{
private static Dictionary<string, bool> Permissions;
public static void Init()
{
Permissions = new Dictionary<string, bool>();
}
private static object _lock = new object();
public static bool HasPermission(string permission)
{
if (string.IsNullOrEmpty(permission)) return false;
lock (_lock)
{
if (Permissions.ContainsKey(permission)) return Permissions[permission];
var hasPermission = true; // Expensive call a third party module to check user permissions.
Permissions.Add(permission, hasPermission);
return hasPermission;
}
}
}
According to the log files provided by the customer, the line Permissions.Add(permission, hasPermission) threw an ArgumentException (key already exists). This doesn't make sense to me; the code checks for the key inside the same lock.
Based on a test run, all calls to HasPermission seem to be made from the main thread. The program uses Dispatcher.BeginInvoke at places, but my understanding is that locking is not even necessary for that. The dictionary is private and not accessed from anywhere else.
In what situation could this exception happen?
My first thought was that the customer was running an old version of the application, but it turns out that this class was only added in the latest one.
This particular exception should be easy enough to avoid by just changing the Permissions.Add(permission, hasPermission) to Permissions[permission] = hasPermission, but I would prefer to understand why it happened first.

It is possible, but hard to tell without the whole source code.
The expensive call
var hasPermission = true; // Expensive call a third party module to check user permissions.
could do something that calls HasPermission() again. Thus, the same thread would enter
lock (_lock) { ... }
again (which is allowed), possibly adding the the permissing, leaving the lock, leaving the method and returning into HasPermission() where it came from, adding the same key again.
This might either require production debugging at your customer. If you're not familiar with that and you can convince your customer to replace the affected DLL for a moment (let him create a backup copy), you could try the following:
lock (_lock)
{
var stack = Environment.StackTrace;
if (stack.Split(new []{nameof(HasPermission)}, StringSplitOptions.None).Length> 2) throw new Exception("I should not be in here twice");
...
}
This should crash the application (unless general catch block somewhere) with a call stack that has the affected method twice, thus you can analyze where the second call comes from. Do whatever you would do in such a case: generate a crash dump, analyze your logs, ...
Generating a stack trace is considerably expensive, so this will change timing and thus potentially make the problem disappear. A disappeared problem is not a fixed problem, though.

I agree with Thomas Weller that the most likely reason is that the same thread reenter the lock for some reason. But i wanted to suggest another approach to these kinds of problems.
Holding a lock while calling arbitrary code can be dangerous, it may lead to deadlocks and various other issues. To limit such risks it is a good idea to only hold locks for short sections of code, only call code you know is safe, and does not raise events or can run arbitrary code some other way.
One option would be to switch to a 'publication only' model for thread safety that releases the lock while calling the 'expensive method'. This might allow multiple threads to call the expensive method at the same time, and this might or might not be an issue in your particular case. Something like:
lock (_lock)
{
if (Permissions.ContainsKey(permission)) return Permissions[permission];
}
var hasPermission = true; // Expensive call a third party module to check user permissions.
lock (_lock)
{
if (Permissions.ContainsKey(permission)) return Permissions[permission];
Permissions.Add(permission, hasPermission);
return hasPermission;
}
Or use ConcurrentDictionary.GetOrAdd that does more or less the same thing.
I would also caution against mutable global state in general since this can also make code hard to read and predict.

As pointed out by JonasH in a comment, the Init method looks highly suspicious. Your program could crash if this method is not called exactly once. If you are not sure how many times it's called, at least protect the code it contains with the same lock.
public static void Init()
{
lock (_lock)
{
Permissions = new Dictionary<string, bool>();
}
}

Should I use a boolean variable to indicate whether a lock has been acquired?

I am currently building a multi-threaded software (in C#), and I am not sure about my solution for a problem.
// isLocked is initialized at earlier stage
if (!isLocked)
{
isLocked = true;
// More code here
}
I know that the condition check is atomic, but i think its possible that another thread will enter the if block before 'isLocked' is assigned the 'true' value (thus creating an unwanted situation).
In Java, i could use AtomicBoolean's method 'compareAndSet' which is atomic, but C#'s equivalent 'CompareExchange' is not atmoic.
I tried using a bool in addition to the lock so that if the "locked" code is already being executed, other threads will bypass it. Is this a good way to do that, or is there a better way?
Object myLock = new object();
bool free = false;
bool isLocked= actorsLocks[i];// Some Data structure
if (!isLocked)
{
lock(mylock)
{
if (!isLocked)
{
isLocked= true;
free = true;
}
}
}
if(free)
{
// actual method code here...
}
Is there a more efficient solution?
Thank you very much in advance.

In Java, i could use AtomicBoolean's method 'compareAndSet' which is
atomic, but C#'s equivalent 'CompareExchange' is not atmoic.
...Uh... yeah it is. Otherwise it would be completely useless.
https://msdn.microsoft.com/en-us/library/801kt583(v=vs.110).aspx#Anchor_2
If comparand and the value in location1 are equal, then value is
stored in location1. Otherwise, no operation is performed. The compare
and exchange operations are performed as an atomic operation. The
return value of CompareExchange is the original value in location1,
whether or not the exchange takes place.
Your solution is close. Make sure your lock object and all variables it protects are accessible by all threads. It won't do you any good to lock a locally-declared object. For example, myLock could be a class data member. It definitely should not be declared in the function. Same thing goes for isLocked.
class C
{
int[] m_actorsLocks; // *See below
...
void WorkerFunction(int threadIndex)
{
if (CompareExchange(ref m_actorsLocks[threadIndex], 1, 0) == 0) // cmpxchg returns old value. If old value was false, it means WE locked it!
{
// do work
// use cmpxchg to free the lock
CompareExchange(ref m_actorsLocks[threadIndex], 0, 1)
// I do this simply because I don't understand how C# caches outgoing writes
// could possibly do m_actorsLocks[threadIndex] = 0; surrounded by Interlocked.MemoryBarrier()
}
else
{
// Threads who didn't get the lock come here...
// If I understand what you're trying to do, you don't want the other threads to wait if they didn't get the lock.
// So you probably wouldn't need this else clause...
}
}
...
};
*If you store your locks in an array, you'll experience false sharing. Since arrays are stored contiguously, your locks will be on the same cache line... you would have the same performance as if you used 1 lock for everything. The grungy way to deal with this is to pad out your array. For example:
// If I want 4 locks
int[] m_actorsLocks = new int[32];
// Now i only use index 0, 8, 16, and 24. The rest are just padding.
It's kinda messy and requires knowlege of your architecture... Better do some research on this one and maybe ask a seperate question.

All you need in C# is:
object theLock = new Object();
lock(theLock)
{
// Lock is yours, enjoy
}

If you want to both attempt to acquire the lock and find out whether you acquired it, in one atomic operation, use Monitor.TryEnter(object).
Monitor.TryEnter returns true if the lock is acquired, false if it isn't. Only execute the "locked" code if TryEnter returns true.
public class SomeClassThatMultipleThreadsAccess
{
private readonly object _lockObject = new object();
public void MethodThatGetsCalledConcurrently()
{
if(Monitor.TryEnter(_lockObject))
{
try
{
// only one thread at a time can execute this in
// one instance of the class.
// If _lockObject is static then only one thread at
// a time can execute this across all instances of
// the class.
}
finally // very important - if we don't exit then nothing else can enter.
{
Monitor.Exit(_lockObject);
}
}
}
}
Note that the object used for locking cannot be declared in the same scope in which it is used.
These both do nothing:
var lockObject = new object();
if(Monitor.TryEnter(lockObject))
var lockObject = new object();
lock(lockObject)
{
because each thread will create a different object, so each thread will immediately acquire the lock. It won't prevent concurrent access to anything ever. There must be one object on which multiple threads attempt to acquire a lock.

In few words: you're asking for trouble. Don't do that.
In more details, there are many factors you underestimate:
CPU conveyor optimization. This means that without proper "do not touch, multiple threads accessing" mark your CPU can modify execution order. And this may do very unexpected things that're absolutely legit in terms of single thread but can ruin your synchronization logic.
Compiler optimization. This can eliminate entire block of code according to Boolean value (and compiler has no idea the bool can be changed by another thread).
False sharing. This is more advanced thing and it can't change your program behavior. However, it can cause significant performance degradation because you read&write your hand-made locks at continuous array (that ruins core-level caches, fastest ones).
This is what can be named right out of the head. If think more, we can find more cons against hand-made thread sync mechanics. So, multithreading is like encryption: do not try to reinvent it, you're dangerously low-informed and would be cracked in minutes or even seconds.

You are right: the read of the bool is atomic but several threads can read atomically the bool and enter the 'if' block before the flag becomes false.
To do what you want (one thread only enters the 'if' block without blocking other threads) you can use kind of :
private long _n = 0;
......
if (Interlocked.Exchange(ref _n, 1) == 0)
{
// More code here, only one thread at a time.
// Be carefull with exceptions.
Interlocked.Exchange(ref _n, 0); // Reset the flag for next running.
}
The Interlocked.Exchange is an atomic read&write: it will block all the threads, except one which will read '_n=0' and write '_n=1' as an atomic operation. The other threads will got 1 immediatly after the interlocked statment returns and they do not enter the block.

Exception on Monitor.Exit in C#

This is a large multi-threaded project (which I didn't write) that I am fixing. The application hangs on some locks which I am tracking down.
I went through and replaced all the "lock" statements with Monitor.TryEnter so I could set a wait period. I am occasionally getting an exception with the Monitor.Exit.
The original style was
private List<myClass> _myVar= new List<myClass>();
if (_myVar != null)
{
lock (_myVar)
{
_myVar = newMyVar; // Where newMyVar is another List<myClass>
}
}
I replaced all my locks like above with:
if (_myVar != null)
{
bool lockTaken = false;
try
{
Monitor.TryEnter(_myVar, new TimeSpan(0, 0, 5), ref lockTaken);
if (lockTaken)
{
_myVar = newMyVar; // Where newMyVar is another List<myClass>
}
}
finally
{
if (lockTaken) Monitor.Exit(_myVar);
}
}
The exception I am getting is
SynchronizationLockException Object synchronization method was called
from an unsynchronized block of code
. If this is true, why doesn't the original lock statement also throw an exception?
Would it be safe to put the Monitor.Exit in a try catch and just ignore it if there is an exception?

It should be very clear why you are getting the exception in your new code. If the lock is taken then the object that is unlocked is not the object that was locked. Locks take an object, not a variable. The correct translation of the deeply wrong original code is
// THIS CODE IS COMPLETELY WRONG; DO NOT USE IT
if (_myVar != null)
{
bool lockTaken = false;
var locker = _myVar;
try
{
Monitor.TryEnter(locker, new TimeSpan(0, 0, 5), ref lockTaken);
if (lockTaken)
{
_myVar = newMyVar; // where newMyVar is another List<myClass>
}
}
finally
{
if (lockTaken) Monitor.Exit(locker);
}
}
Which will not throw on exit, but is still completely wrong.
Never lock on the contents of a variable and then mutate the variable; every subsequent lock will lock on a different object! So you have no mutual exclusion.
And never lock on a public object! If that list leaks out anywhere then other wrong code can be locking on that list in an unexpected order, which means deadlocks -- which is the original symptom you are diagnosing.
The correct practice for locking on a field is to create a private readonly object field used only as a locker, and used every time the field is accessed. That way you know that (1) the field is always accessed under the same lock, no matter its value, and (2) the lock object is used only for locking that field, and not for locking something else. That ensures mutual exclusion and prevents deadlocks.
The fact that someone wrote a large multithreaded program without understanding the most basic facts about locks means that it is almost certainly a complete mess of hard-to-find bugs. The fact that this wasn't immediately obvious upon reading the code means that you don't have enough knowledge of threading to fix the problems correctly. You're going to need to either find an expert on this stuff who can help you, or gain at least a minimal working knowledge of correct practices.
I cannot emphasize enough that this is hard stuff. Programs with multiple threads of control in them are extremely difficult to write correctly on modern hardware; many of the things you believe are guaranteed by the language are only guaranteed in single threaded programs.

ReaderWriterLockSection: A bad idea?

In writing some threaded code, I've been using the ReaderWriterLockSlim class to handle synchronized access to variables. Doing this, I noticed I was always writing try-finally blocks, the same for each method and property.
Seeing an opportunity to avoid repeating myself and encapsulate this behaviour I built a class, ReaderWriterLockSection, intended to be used as a thin wrapper to the lock which can be used with the C# using block syntax.
The class is mostly as follows:
public enum ReaderWriterLockType
{
Read,
UpgradeableRead,
Write
}
public class ReaderWriterLockSection : IDisposeable
{
public ReaderWriterLockSection(
ReaderWriterLockSlim lock,
ReaderWriterLockType lockType)
{
// Enter lock.
}
public void UpgradeToWriteLock()
{
// Check lock can be upgraded.
// Enter write lock.
}
public void Dispose()
{
// Exit lock.
}
}
I use the section as follows:
private ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();
public void Foo()
{
using(new ReaderWriterLockSection(_lock, ReaderWriterLockType.Read)
{
// Do some reads.
}
}
To me, this seems like a good idea, one that makes my code easier to read and seemingly more robust since I wont ever forget to release a lock.
Can anybody see an issue with this approach? Is there any reason this is a bad idea?

Well, it seems okay to me. Eric Lippert has previously written about the dangers of using Dispose for "non-resource" scenarios, but I think this would count as a resource.
It may make life tricky in upgrade scenarios, but you could always fall back to a more manual bit of code at that point.
Another alternative is to write a single lock acquire/use/release method and provide the action to take while holding the lock as a delegate.

I usually indulge into this kind of code-sugary confections!
Here's a variant that's a bit easier to read for the users, on top of your API
public static class ReaderWriterLockExt{
public static IDisposable ForRead(ReaderWriterLockSlim rwLock){
return new ReaderWriterLockSection(rwLock,ReaderWriterLockType.Read);
}
public static IDisposable ForWrite(ReaderWriterLockSlim rwLock){
return new ReaderWriterLockSection(rwLock,ReaderWriterLockType.Write);
}
public static IDisposable ForUpgradeableRead(ReaderWriterLockSlim wrLock){
return new ReaderWriterLockSection(rwLock,ReaderWriterLockType.UpgradeableRead);
}
}
public static class Foo(){
private static readonly ReaderWriterLockSlim l=new ReaderWriterLockSlim(); // our lock
public static void Demo(){
using(l.ForUpgradeableRead()){ // we might need to write..
if(CacheExpires()){ // checks the scenario where we need to write
using(l.ForWrite()){ // will request the write permission
RefreshCache();
} // relinquish the upgraded write
}
// back into read mode
return CachedValue();
} // release the read
}
}
I also recommend using a variant that takes an Action delegate that's invoked when the lock cannot be obtained for 10 seconds, which I'll leave as an exercise to the reader.
You might also want to check for a null RWL in the static extension methods, and make sure the lock exists when you dispose it.
Cheers,
Florian

There is another consideration here, you are possibly solving a problem you should not solve. I can't see the rest of your code but I can guess from you seeing value in this pattern.
Your approach solves a problem only if the code that reads or writes the shared resource throws an exception. Implicit is that you don't handle the exception in the method that does the reading/writing. If you did, you could simply release the lock in the exception handling code. If you don't handle the exception at all, the thread will die from the unhandled exception and your program will terminate. No point in releasing a lock then.
So there's a catch clause somewhere lower in the call stack that catches the exception and handles it. This code has to restore the state of the program so that it can meaningful continue without generating bad data or otherwise die due to exceptions caused by altered state. That code has a difficult job to do. It needs to somehow guess how much data was read or written without having any context. Getting it wrong, or only partly right, is potentially very destabilizing to the entire program. After all, it was a shared resource, other threads are reading/writing from it.
If you know how to do this, then by all means use this pattern. You better test the heck out of though. If you're not sure then avoid wasting system resources on a problem you can't reliably fix.

One thing I'd suggest when wrapping a lock to facilitate the "using" pattern is to include a "danger-state" field in the lock; before allowing any code to enter the lock, the code should check the danger state. If the danger state is set, and the code which is trying to enter the lock hasn't passed a special parameter saying it's expecting that it might be, the attempt to acquire the lock should throw an exception. Code which is going to temporarily put the guarded resource into a bad state should set the danger state flag, do what needs to be done, and then reset the danger state flag once the operation is complete and the object is in a safe state.
If an exception occurs while the danger state flag is set, the lock should be released but the danger state flag should remain set. This will ensure that code which wants to access the resource will find out that the resource is corrupted, rather than waiting forever for the lock to be released (which would be the outcome if there were no "using" or "try-finally" block).
If the lock being wrapped is a ReaderWriterLock, it may be convenient to have the acquisition of a "writer" lock automatically set the danger state; unfortunately, there's no way for an IDisposable used by a using block to determine whether the block is being exited cleanly or via exception. Consequently, I don't know any way to use something syntactically like a 'using' block to guard the "danger state" flag.

How to make a method exclusive in a multithreaded context?

I have a method which should be executed in an exclusive fashion. Basically, it's a multi threaded application where the method is invoked periodically by a timer, but which could also be manually triggered by a user action.
Let's take an example :
The timer elapses, so the method is
called. The task could take a few
seconds.
Right after, the user clicks on some
button, which should trigger the
same task : BAM. It does nothing
since the method is already running.
I used the following solution :
public void DoRecurentJob()
{
if(!Monitor.TryEnter(this.lockObject))
{
return;
}
try
{
// Do work
}
finally
{
Monitor.Exit(this.lockObject);
}
}
Where lockObject is declared like that:
private readonly object lockObject = new object();
Edit : There will be only one instance of the object which holds this method, so I updated the lock object to be non-static.
Is there a better way to do that ? Or maybe this one is just wrong for any reason ?

This looks reasonable if you are just interested in not having the method run in parallel. There's nothing to stop it from running immediately after each other, say that you pushed the button half a microsecond after the timer executed the Monitor.Exit().
And having the lock object as readonly static also make sense.

You could also use Mutex or Semaphore if you want it to work cross process (with a slight performance penalty), or if you need to set any other number than one of allowed simultaneous threads running your piece of code.
There are other signalling constructs that would work, but your example looks like it does the trick, and in a simple and straightforward manner.

Minor nit: if the lockObject variable is static, then "this.lockObject" shouldn't compile. It also feels slightly odd (and should at least be heavily documented) that although this is an instance method, it has distinctly type-wide behaviour as well. Possibly make it a static method which takes an instance as the parameter?
Does it actually use the instance data? If not, make it static. If it does, you should at least return a boolean to say whether or not you did the work with the instance - I find it hard to imagine a situation where I want some work done with a particular piece of data, but I don't care if that work isn't performed because some similar work was being performed with a different piece of data.
I think it should work, but it does feel a little odd. I'm not generally a fan of using manual locking, just because it's so easy to get wrong - but this does look okay. (You need to consider asynchronous exceptions between the "if" and the "try" but I suspect they won't be a problem - I can't remember the exact guarantees made by the CLR.)

I think Microsoft recommends using the lock statement, instead of using the Monitor class directly. It gives a cleaner layout and ensures the lock is released in all circumstances.
public class MyClass
{
// Used as a lock context
private readonly object myLock = new object();
public void DoSomeWork()
{
lock (myLock)
{
// Critical code section
}
}
}
If your application requires the lock to span all instances of MyClass you can define the lock context as a static field:
private static readonly object myLock = new object();

The code is fine, but would agree with changing the method to be static as it conveys intention better. It feels odd that all instances of a class have a method between them that runs synchronously, yet that method isn't static.
Remember you can always have the static syncronous method to be protected or private, leaving it visible only to the instances of the class.
public class MyClass
{
public void AccessResource()
{
OneAtATime(this);
}
private static void OneAtATime(MyClass instance)
{
if( !Monitor.TryEnter(lockObject) )
// ...

This is a good solution although I'm not really happy with the static lock. Right now you're not waiting for the lock so you won't get into trouble with deadlocks. But making locks too visible can easily get you in to trouble the next time you have to edit this code. Also this isn't a very scalable solution.
I usually try to make all the resources I try to protect from being accessed by multiple threads private instance variables of a class and then have a lock as a private instance variable too. That way you can instantiate multiple objects if you need to scale.

A more declarative way of doing this is using the MethodImplOptions.Synchronized specifier on the method to which you wish to synchronize access:
[MethodImpl(MethodImplOptions.Synchronized)]
public void OneAtATime() { }
However, this method is discouraged for several reasons, most of which can be found here and here. I'm posting this so you won't feel tempted to use it. In Java, synchronized is a keyword, so it may come up when reviewing threading patterns.

We have a similar requirement, with the added requirement that if the long-running process is requested again, it should enqueue to perform another cycle after the current cycle is complete. It's similar to this:
https://codereview.stackexchange.com/questions/16150/singleton-task-running-using-tasks-await-peer-review-challenge
private queued = false;
private running = false;
private object thislock = new object();
void Enqueue() {
queued = true;
while (Dequeue()) {
try {
// do work
} finally {
running = false;
}
}
}
bool Dequeue() {
lock (thislock) {
if (running || !queued) {
return false;
}
else
{
queued = false;
running = true;
return true;
}
}
}