Develop Reference

Signal and Wait in C#

In the below application there are two parties that are calling ChannelReservationCache to fetch or add information.
I want to use the "signal and wait" thing in my ChannelReservationCache class so that in case ChannelReservationCache.AddChannelState() is adding the cache, parallelly if the WebApi call hits the ChannelReservationCache.GetChannel() then the GetChannel() should wait for the execution of AddChannelState() and vice-versa.
How this can be done in ChannelReservationCache class?
Will there be any deadlock?
public class ChannelReservationCache
{
private readonly IDictionary<int, string> channelStates = new Dictionary<int, string>>();
private readonly object lockObject = new object();
private static readonly object lock = new object();
private static ChannelReservationCache instance = null;
private ChannelReservationCache() {}
public static ChannelReservationCache Instance
{
get
{
lock(lock) {
if (instance == null) {
instance = new ChannelReservationCache();
}
return instance;
}
}
}
public void AddChannelState(int level, string channel)
{
lock (this.lockObject)
{
//other code that makes the function take long time.
this.AddChannel(level, channel);
}
}
public Channel GetChannel(int level)
{
//other code that makes the function take long time.
Channel c = new Channel()
channelStates.TryGetValue(destinationId, out var c);
return c;
}
private void AddChannel(int level, string channel)
{
Channel c = new Channel();
c.ChannelName = channel;
c.IsActive = true;
channelStates.Add(level, resourceState)
}
}
public class Channel
{
public string ChannelName {get; set;}
public bool IsActive {get; set;}
}
public class RMQRequestHandler
{
public Task HandleChannelRequest(int level, Channel messages)
{
ChannelReservationCache.Instance.AddChannelState(level, messages)
}
}
[Route("api/v1")]
public class ChannnelController: ControllerBase
{
[HttpGet]
[Route("ChannelResource")]
public IActionResult GetChannelResource([FromQuery] int id)
{
ChannelReservationCache crc = ChannelReservationCache.Instance.GetChannel(id);
return this.Ok(crc);
}
}

First off there is a far simpler solution for you:
Simply change
private readonly IDictionary<int, string> channelStates = new Dictionary<int, string>();
To:
private readonly IDictionary<int, string> channelStates = new System.Collections.Concurrent.ConcurrentDictionary<int, string>();
//using ConcurrentDictionary instead of Dictionary
And forget about the thread concurrency locking etc...
In reality it is pretty hard to beat the performance of ConcurrentDictionary by writing our own locking structures to wrap a normal Dictionary. It is possible using ReaderWriterLockSlim to lock the dictionary and Interlocked to maintain a custom implementation for its count property. But this is a micro optimization that would only pay out over millions of itterations.
Now to answer your question:
One issue here:
AddChannelState is threadsafe but GetChannel is not
Think of it this way. Your writer is using a threadsafe lock but your reader is not. GetChannel also needs a lock in it.
Suggestion
If you are Not using Lazy < T > in your singleton then it is probably best to make the following change
Code Example below where the cost of thread synchronization is avoided after it has been initialized. Bearing in mind that Lock (or Monitor.Enter / Exit) is one of the most expensive operations to perform. Sure there will be minimum locking contentions once it is initialized however the memory barrier is enforced each and every time plus the Monitor is being checked.
Following reference link is discussing Interlocked but the context of the memory barrier cost is the same:
https://learn.microsoft.com/en-us/archive/msdn-magazine/2005/october/understanding-low-lock-techniques-in-multithreaded-apps
private static ChannelReservationCache instance;
private static readonly object lockInstance = new object();
//lock (lockInstance) enforces a memory barrier plus the monitor which is a cost you do not need to bear once the instance has been initialized
public static ChannelReservationCache Instance
{
get
{
if (instance == null)
{
lock (lockInstance)
{
if (instance == null)
{
instance = new ChannelReservationCache();
}
}
}
return instance;
}
}

Where is the flaw in my algorithm to lock a critical section by a key (string)?

Attempt:
public class KeyLock : IDisposable
{
private string key;
private static ISet<string> lockedKeys = new HashSet<string>();
private static object locker1 = new object();
private static object locker2 = new object();
public KeyLock(string key)
{
lock(locker2)
{
// wait for key to be freed up
while(lockedKeys.Contains(key));
this.lockedKeys.Add(this.key = key);
}
}
public void Dispose()
{
lock(locker)
{
lockedKeys.Remove(this.key);
}
}
}
to be used like
using(new KeyLock(str))
{
// section that is critical based on str
}
I test by firing the method twice in the same timespan
private async Task DoStuffAsync(string str)
{
using(new KeyLock(str))
{
await Task.Delay(1000);
}
}
// ...
await Task.WhenAll(DoStuffAsync("foo"), DoStuffAsync("foo"))
but, strangely enough, when I debug I see that the second time it goes straight through the lock and in fact somehow lockedKeys.Contains(key) evaluates to false even through I can see in my debugger windows that the key is there.
Where is the flaw and how do I fix it?

Take a look at lock statement (C# Reference)
It basically breaks down to
object __lockObj = x;
bool __lockWasTaken = false;
try
{
System.Threading.Monitor.Enter(__lockObj, ref __lockWasTaken);
// Your code...
}
finally
{
if (__lockWasTaken) System.Threading.Monitor.Exit(__lockObj);
}
Enter(Object)
Acquires an exclusive lock on the specified object.
What you need to do instead, is keep around and obtain the same reference. You could probably use a thread safe Dictionary ConcurrentDictionary
public static ConcurrentDictionary<string, object> LockMap = new ConcurrentDictionary<string, object> ();
...
lock (LockMap.GetOrAdd(str, x => new object ()))
{
// do locky stuff
}
Note : This is just one example of many ways to do this, you will obviously need to tweak it for your needs

The main problems that I notice are as follows:
※Super dangerous infinite loop in the constructor, and super wasteful as well.
※When accessing the private field lockedKeys, you use different objects to lock on→ Not good
However, why your code does not seem to be working I think is because of the short delay you set. Since it is only 1 second of delay during the debugging when you step from statement to statement, 1 second already passes and it gets disposed.
using(new KeyLock(str)){
await Task.Delay(1000);
}
Luckily for you, I came across a similar problem before and I have a solution, too. Look here for my small solution.
Usage:
//Resource to be shared
private AsyncLock _asyncLock = new AsyncLock();
....
....
private async Task DoStuffAsync()
{
using(await _asyncLock.LockAsync())
{
await Task.Delay(1000);
}
}
// ...
await Task.WhenAll(DoStuffAsync(), DoStuffAsync())

Prevent two threads entering a code block with the same value

Say I have this function (assume I'm accessing Cache in a threadsafe way):
object GetCachedValue(string id)
{
if (!Cache.ContainsKey(id))
{
//long running operation to fetch the value for id
object value = GetTheValueForId(id);
Cache.Add(id, value);
}
return Cache[id];
}
I want to prevent two threads from running the "long running operation" at the same time for the same value. Obviously I can wrap the whole thing in a lock(), but then the whole function would block regardless of value and I want two threads to be able to perform the long running operation as long as they're looking for different id's.
Is there a built-in locking mechanism to lock based on a value so one thread can block while the other thread completes the long running operation so I don't need to do it twice (or N times)? Ideally as long as the long running operation is being performed in one thread, no other thread should be able to do it for the same id value.
I could roll my own by putting the id's in a HashSet and then removing them once the operation completes, but that seems like a hack.

I would use Lazy<T> here. Below code will lock the cache, put the Lazy into the cache and return immediately. Long-running-operation will be executed once in a thread safe manner.
new Thread(() => Console.WriteLine("1-" + GetCachedValue("1").Value)).Start();
new Thread(() => Console.WriteLine("2-" + GetCachedValue("1").Value)).Start();
Lazy<object> GetCachedValue(string id)
{
lock (Cache)
{
if (!Cache.ContainsKey(id))
{
Lazy<object> lazy = new Lazy<object>(() =>
{
Console.WriteLine("**Long Running Job**");
Thread.Sleep(3000);
return int.Parse(id);
},
true);
Cache.Add(id, lazy);
Console.WriteLine("added to cache");
}
return Cache[id];
}
}

In this case I would like to have interface like this
using (SyncDispatcher.Enter(id))
{
//any code here...
}
so I could execute any code and it would be thread safe if id is the same.
If I need to get value from Cache I get it straight forward, as just there is no concurrency calls.
My implementation for SyncDispatcher is this:
public class SyncDispatcher : IDisposable
{
private static object _lock = new object();
private static Dictionary<object, SyncDispatcher> _container = new Dictionary<object, SyncDispatcher>();
private AutoResetEvent _syncEvent = new AutoResetEvent(true);
private SyncDispatcher() { }
private void Lock()
{
_syncEvent.WaitOne();
}
public void Dispose()
{
_syncEvent.Set();
}
public static SyncDispatcher Enter(object obj)
{
var objDispatcher = GetSyncDispatcher(obj);
objDispatcher.Lock();
return objDispatcher;
}
private static SyncDispatcher GetSyncDispatcher(object obj)
{
lock (_lock)
{
if (!_container.ContainsKey(obj))
{
_container.Add(obj, new SyncDispatcher());
}
return _container[obj];
}
}
}
Simple test:
static void Main(string[] args)
{
new Thread(() => Execute("1", 1000, "Resource 1")).Start();
new Thread(() => Execute("2", 200, "Resource 2")).Start();
new Thread(() => Execute("1", 0, "Resource 1 again")).Start();
}
static void Execute(object id, int timeout, string message)
{
using (SyncDispatcher.Enter(id))
{
Thread.Sleep(timeout);
Console.WriteLine(message);
}
}

Move your locking down to where your comment is. I think you need to maintain a list of currently-executing long running operations, and lock accesses to that list, and only execute the GetValueForId if the id you're looking for isn't in that list. I'll try and whip something up.
private List<string> m_runningCacheIds = new List<string>();
object GetCachedValue(string id)
{
if (!Cache.ContainsKey(id))
{
lock (m_runningCacheIds) {
if (m_runningCacheIds.Contains(id)) {
// Do something to wait until the other Get is done....
}
else {
m_runningCacheIds.Add(id);
}
}
//long running operation to fetch the value for id
object value = GetTheValueForId(id);
Cache.Add(id, value);
lock (m_runningCacheIds)
m_runningCacheIds.Remove(id);
}
return Cache[id];
}
There's still the issue of what the thread is going to do while it waits on the other thread is getting the value.

I use in that cases the Mutex as:
object GetCachedValue(string Key)
{
// note here that I use the key as the name of the mutex
// also here you need to check that the key have no invalid charater
// to used as mutex name.
var mut = new Mutex(true, key);
try
{
// Wait until it is safe to enter.
mut.WaitOne();
// here you create your cache
if (!Cache.ContainsKey(Key))
{
//long running operation to fetch the value for id
object value = GetTheValueForId(Key);
Cache.Add(Key, value);
}
return Cache[Key];
}
finally
{
// Release the Mutex.
mut.ReleaseMutex();
}
}
Notes:
Some characters are not valid for the mutex name (like the slash)
If the Cache is different for every application (or web pool) that you use, and it is if we speak for the cache of asp.net, then the mutex is lock all threads and pools in the computer, in this case I also use a static random integer that I add it to the key, and not make the lock different for each key but also for each pool.

It's not the most elegant solution in the world, but I've gotten around this issue with a double check and a lock:
object GetCachedValue(string id)
{
if (!Cache.ContainsKey(id))
{
lock (_staticObj)
{
if (!Cache.ContainsKey(id))
{
//long running operation to fetch the value for id
object value = GetTheValueForId(id);
Cache.Add(id, value);
}
}
}
return Cache[id];
}

How to use lock on a Dictionary containing a list of objects in C#?

I have the following class:
public static class HotspotsCache
{
private static Dictionary<short, List<HotSpot>> _companyHotspots = new Dictionary<int, List<HotSpot>>();
private static object Lock = new object();
public static List<HotSpot> GetCompanyHotspots(short companyId)
{
lock (Lock)
{
if (!_companyHotspots.ContainsKey(companyId))
{
RefreshCompanyHotspotCache(companyId);
}
return _companyHotspots[companyId];
}
}
private static void RefreshCompanyHotspotCache(short companyId)
{
....
hotspots = ServiceProvider.Instance.GetService<HotspotsService>().GetHotSpots(..);
_companyHotspots.Add(companyId, hotspots);
....
}
The issue that I'm having is that the operation of getting the hotspots, in RefreshCompanyHotspotCache method, takes a lot of time . So while one thread is performing the cache refresh for a certain CompanyId, all the other threads are waiting until this operation is finished, although there could be threads that are requesting the list of hotspots for another companyId for which the list is already loaded in the dictionary. I would like these last threads not be locked. I also want that all threads that are requesting the list of hotspots for a company that is not yet loaded in the cache to wait until the list is fully retrieved and loaded in the dictionary.
Is there a way to lock only the threads that are reading/writing the cache for certain companyId (for which the refresh is taking place) and let the other threads that are requesting data for another company to do their job?
My thought was to use and array of locks
lock (companyLocks[companyId])
{
...
}
But that didn't solve anything. The threads dealing with one company are still waiting for threads that are refreshing the cache for other companies.

Use the Double-checked lock mechanism also mentioned by Snowbear - this will prevent your code locking when it doesn't actually need to.
With your idea of an individual lock per client, I've used this mechanism in the past, though I used a dictionary of locks. I made a utility class for getting a lock object from a key:
/// <summary>
/// Provides a mechanism to lock based on a data item being retrieved
/// </summary>
/// <typeparam name="T">Type of the data being used as a key</typeparam>
public class LockProvider<T>
{
private object _syncRoot = new object();
private Dictionary<T, object> _lstLocks = new Dictionary<T, object>();
/// <summary>
/// Gets an object suitable for locking the specified data item
/// </summary>
/// <param name="key">The data key</param>
/// <returns></returns>
public object GetLock(T key)
{
if (!_lstLocks.ContainsKey(key))
{
lock (_syncRoot)
{
if (!_lstLocks.ContainsKey(key))
_lstLocks.Add(key, new object());
}
}
return _lstLocks[key];
}
}
So simply use this in the following manner...
private static LockProvider<short> _clientLocks = new LockProvider<short>();
private static Dictionary<short, List<HotSpot>> _companyHotspots = new Dictionary<short, List<HotSpot>>();
public static List<HotSpot> GetCompanyHotspots(short companyId)
{
if (!_companyHotspots.ContainsKey(companyId))
{
lock (_clientLocks.GetLock(companyId))
{
if (!_companyHotspots.ContainsKey(companyId))
{
// Add item to _companyHotspots here...
}
}
return _companyHotspots[companyId];
}

How about you only lock 1 thread, and let that update, while everyone else uses the old list?
private static Dictionary<short, List<HotSpot>> _companyHotspots = new Dictionary<short, List<HotSpot>>();
private static Dictionary<short, List<HotSpot>> _companyHotspotsOld = new Dictionary<short, List<HotSpot>>();
private static bool _hotspotsUpdating = false;
private static object Lock = new object();
public static List<HotSpot> GetCompanyHotspots(short companyId)
{
if (!_hotspotsUpdating)
{
if (!_companyHotspots.ContainsKey(companyId))
{
lock (Lock)
{
_hotspotsUpdating = true;
_companyHotspotsOld = _companyHotspots;
RefreshCompanyHotspotCache(companyId);
_hotspotsUpdating = false;
return _companyHotspots[companyId];
}
}
else
{
return _companyHotspots[companyId];
}
}
else
{
return _companyHotspotsOld[companyId];
}
}

Have you looked into ReaderWriterLockSlim? That should be able to let get finer grained locking where you only take a writelock when needed.
Another thing you may need to look out for is false sharing. I don't know how a lock is implemented exactly but if you lock on objects in an array they're bound to be close to each other in memory, possibly putting them on the same cacheline, so the lock may not behave as you expect.
Another idea, what happens if you change the last code snippet to
object l = companyLocks[companyId];
lock(l){
}
could be the lock statement wraps more here than intended.
GJ

New idea, with locking just the lists as they are created.
If you can guarantee that each company will have at least one hotspot, do this:
public static class HotspotsCache
{
private static Dictionary<short, List<HotSpot>> _companyHotspots = new Dictionary<int, List<HotSpot>>();
static HotspotsCache()
{
foreach(short companyId in allCompanies)
{
companyHotspots.Add(companyId, new List<HotSpot>());
}
}
public static List<HotSpot> GetCompanyHotspots(short companyId)
{
List<HotSpots> result = _companyHotspots[companyId];
if(result.Count == 0)
{
lock(result)
{
if(result.Count == 0)
{
RefreshCompanyHotspotCache(companyId, result);
}
}
}
return result;
}
private static void RefreshCompanyHotspotCache(short companyId, List<HotSpot> resultList)
{
....
hotspots = ServiceProvider.Instance.GetService<HotspotsService>().GetHotSpots(..);
resultList.AddRange(hotspots);
....
}
}
Since the dictionary is being modified after its initial creation, no need to do any locking on it. We only need to lock the individual lists as we populate them, the read operation needs no locking (including the initial Count == 0).

If you're able to use .NET 4 then the answer is straightforward -- use a ConcurrentDictionary<K,V> instead and let that look after the concurrency details for you:
public static class HotSpotsCache
{
private static readonly ConcurrentDictionary<short, List<HotSpot>>
_hotSpotsMap = new ConcurrentDictionary<short, List<HotSpot>>();
public static List<HotSpot> GetCompanyHotSpots(short companyId)
{
return _hotSpotsMap.GetOrAdd(companyId, id => LoadHotSpots(id));
}
private static List<HotSpot> LoadHotSpots(short companyId)
{
return ServiceProvider.Instance
.GetService<HotSpotsService>()
.GetHotSpots(/* ... */);
}
}
If you're not able to use .NET 4 then your idea of using several more granular locks is a good one:
public static class HotSpotsCache
{
private static readonly Dictionary<short, List<HotSpot>>
_hotSpotsMap = new Dictionary<short, List<HotSpot>();
private static readonly object _bigLock = new object();
private static readonly Dictionary<short, object>
_miniLocks = new Dictionary<short, object>();
public static List<HotSpot> GetCompanyHotSpots(short companyId)
{
List<HotSpot> hotSpots;
object miniLock;
lock (_bigLock)
{
if (_hotSpotsMap.TryGetValue(companyId, out hotSpots))
return hotSpots;
if (!_miniLocks.TryGetValue(companyId, out miniLock))
{
miniLock = new object();
_miniLocks.Add(companyId, miniLock);
}
}
lock (miniLock)
{
if (!_hotSpotsMap.TryGetValue(companyId, out hotSpots))
{
hotSpots = LoadHotSpots(companyId);
lock (_bigLock)
{
_hotSpotsMap.Add(companyId, hotSpots);
_miniLocks.Remove(companyId);
}
}
return hotSpots;
}
}
private static List<HotSpot> LoadHotSpots(short companyId)
{
return ServiceProvider.Instance
.GetService<HotSpotsService>()
.GetHotSpots(/* ... */);
}
}

C#: Can you detect whether or not the current execution context is within `lock (this)`?

If I have an object that I would like to force to be accessed from within a lock, like so:
var obj = new MyObject();
lock (obj)
{
obj.Date = DateTime.Now;
obj.Name = "My Name";
}
Is it possible, from within the AddOne and RemoveOne functions to detect whether the current execution context is within a lock?
Something like:
Monitor.AreWeCurrentlyEnteredInto(this)
Edit: (for clarification of intent)
The intent here is to be able to reject any modification made outside of the lock, so that all changes to the object itself will be transactional and thread-safe. Locking on a mutex within the object itself does not ensure a transactional nature to the edits.
I know that it is possible to do this:
var obj = new MyObject();
obj.MonitorEnterThis();
try
{
obj.Date = DateTime.Now;
obj.Name = "My Name";
}
finally
{
obj.MonitorExitThis();
}
But this would allow any other thread to call the Add/Remove functions without first calling the Enter, thereby circumventing the protection.
Edit 2:
Here is what I'm currently doing:
var obj = new MyObject();
using (var mylock = obj.Lock())
{
obj.SetDate(DateTime.Now, mylock);
obj.SetName("New Name", mylock);
}
Which is simple enough, but it has two problems:
I'm implementing IDisposable on the
mylock object, which is a little bit
of an abuse of the IDisposable
interface.
I would like to change the SetDate and SetName functions to
Properties, for clarity.

I don't think that's possible without tracking the state yourself (e.g. by using some kind of semaphore). But even if it were, that'd be a gross violation of encapsulation. Your methods usually shouldn't care whether or not they're executing in a particular locking context.

There's no documented method of checking for this kind of condition at runtime, and if there were, I'd be suspicious of any code that used it, because any code that alters its behaviour based on the call stack would be very difficult to debug.
True ACID semantics are not trivial to implement, and I personally wouldn't try; that's what we have databases for, and you can use an in-memory database if you need the code to be fast/portable. If you just want forced-single-threaded semantics, that is a somewhat easier beast to tame, although as a disclaimer I should mention that in the long run you'd be better off simply providing atomic operations as opposed to trying to prevent multi-threaded access.
Let's suppose that you have a very good reason for wanting to do this. Here is a proof-of-concept class you could use:
public interface ILock : IDisposable
{
}
public class ThreadGuard
{
private static readonly object SlotMarker = new Object();
[ThreadStatic]
private static Dictionary<Guid, object> locks;
private Guid lockID;
private object sync = new Object();
public void BeginGuardedOperation()
{
lock (sync)
{
if (lockID == Guid.Empty)
throw new InvalidOperationException("Guarded operation " +
"was blocked because no lock has been obtained.");
object currentLock;
Locks.TryGetValue(lockID, out currentLock);
if (currentLock != SlotMarker)
{
throw new InvalidOperationException("Guarded operation " +
"was blocked because the lock was obtained on a " +
"different thread from the calling thread.");
}
}
}
public ILock GetLock()
{
lock (sync)
{
if (lockID != Guid.Empty)
throw new InvalidOperationException("This instance is " +
"already locked.");
lockID = Guid.NewGuid();
Locks.Add(lockID, SlotMarker);
return new ThreadGuardLock(this);
}
}
private void ReleaseLock()
{
lock (sync)
{
if (lockID == Guid.Empty)
throw new InvalidOperationException("This instance cannot " +
"be unlocked because no lock currently exists.");
object currentLock;
Locks.TryGetValue(lockID, out currentLock);
if (currentLock == SlotMarker)
{
Locks.Remove(lockID);
lockID = Guid.Empty;
}
else
throw new InvalidOperationException("Unlock must be invoked " +
"from same thread that invoked Lock.");
}
}
public bool IsLocked
{
get
{
lock (sync)
{
return (lockID != Guid.Empty);
}
}
}
protected static Dictionary<Guid, object> Locks
{
get
{
if (locks == null)
locks = new Dictionary<Guid, object>();
return locks;
}
}
#region Lock Implementation
class ThreadGuardLock : ILock
{
private ThreadGuard guard;
public ThreadGuardLock(ThreadGuard guard)
{
this.guard = guard;
}
public void Dispose()
{
guard.ReleaseLock();
}
}
#endregion
}
There's a lot going on here but I'll break it down for you:
Current locks (per thread) are held in a [ThreadStatic] field which provides type-safe, thread-local storage. The field is shared across instances of the ThreadGuard, but each instance uses its own key (Guid).
The two main operations are GetLock, which verifies that no lock has already been taken and then adds its own lock, and ReleaseLock, which verifies that the lock exists for the current thread (because remember, locks is ThreadStatic) and removes it if that condition is met, otherwise throws an exception.
The last operation, BeginGuardedOperation, is intended to be used by classes that own ThreadGuard instances. It's basically an assertion of sorts, it verifies that the currently-executed thread owns whichever lock is assigned to this ThreadGuard, and throws if the condition isn't met.
There's also an ILock interface (which doesn't do anything except derive from IDisposable), and a disposable inner ThreadGuardLock to implement it, which holds a reference to the ThreadGuard that created it and calls its ReleaseLock method when disposed. Note that ReleaseLock is private, so the ThreadGuardLock.Dispose is the only public access to the release function, which is good - we only want a single point of entry for acquisition and release.
To use the ThreadGuard, you would include it in another class:
public class MyGuardedClass
{
private int id;
private string name;
private ThreadGuard guard = new ThreadGuard();
public MyGuardedClass()
{
}
public ILock Lock()
{
return guard.GetLock();
}
public override string ToString()
{
return string.Format("[ID: {0}, Name: {1}]", id, name);
}
public int ID
{
get { return id; }
set
{
guard.BeginGuardedOperation();
id = value;
}
}
public string Name
{
get { return name; }
set
{
guard.BeginGuardedOperation();
name = value;
}
}
}
All this does is use the BeginGuardedOperation method as an assertion, as described earlier. Note that I'm not attempting to protect read-write conflicts, only multiple-write conflicts. If you want reader-writer synchronization then you'd need to either require the same lock for reading (probably not so good), use an additional lock in MyGuardedClass (the most straightforward solution) or alter the ThreadGuard to expose and acquire a true "lock" using the Monitor class (be careful).
And here's a test program to play with:
class Program
{
static void Main(string[] args)
{
MyGuardedClass c = new MyGuardedClass();
RunTest(c, TestNoLock);
RunTest(c, TestWithLock);
RunTest(c, TestWithDisposedLock);
RunTest(c, TestWithCrossThreading);
Console.ReadLine();
}
static void RunTest(MyGuardedClass c, Action<MyGuardedClass> testAction)
{
try
{
testAction(c);
Console.WriteLine("SUCCESS: Result = {0}", c);
}
catch (Exception ex)
{
Console.WriteLine("FAIL: {0}", ex.Message);
}
}
static void TestNoLock(MyGuardedClass c)
{
c.ID = 1;
c.Name = "Test1";
}
static void TestWithLock(MyGuardedClass c)
{
using (c.Lock())
{
c.ID = 2;
c.Name = "Test2";
}
}
static void TestWithDisposedLock(MyGuardedClass c)
{
using (c.Lock())
{
c.ID = 3;
}
c.Name = "Test3";
}
static void TestWithCrossThreading(MyGuardedClass c)
{
using (c.Lock())
{
c.ID = 4;
c.Name = "Test4";
ThreadPool.QueueUserWorkItem(s => RunTest(c, cc => cc.ID = 5));
Thread.Sleep(2000);
}
}
}
As the code (hopefully) implies, only the TestWithLock method completely succeeds. The TestWithCrossThreading method partially succeeds - the worker thread fails, but the main thread has no trouble (which, again, is the desired behaviour here).
This isn't intended to be production-ready code, but it should give you the basic idea of what has to be done in order to both (a) prevent cross-thread calls and (b) allow any thread to take ownership of the object as long as nothing else is using it.

Lets redisgn your class to make it actually work like transaction.
using (var transaction = account.BeginTransaction())
{
transaction.Name = "blah";
transaction.Date = DateTime.Now;
transaction.Comit();
}
Changes will not be propagated until commit is called.
In commit you can take a lock and set the properties on the target object.

You can override AddOne and RemoveOne to take a boolean flag that is set to true if it's being called from a lock. I don't see any other way.
You can also play with the ExecutionContext class if you want to know something about the current execution context. You can get the current context by calling ExecutionContext.Capture().

using thread local storage you can store the entering and exiting of a lock.

If your requirement is that the lock must be acquired for the duration of either method AddOne() or RemoveOne(), then why not simply acquire the lock inside each method? It shouldn't be a problem if the caller has already acquired the lock for you.
However, if your requirement is that the lock must be acquired before calling AddOne() and RemoveOne() together (because other concurrent operations performed on the instance are potentially unsafe), then maybe you should consider changing the public interface so that locking can be handled internally without concerning client code with the details.
One possible way to accomplish the later would be to provide methods for Begin- and End-Changes that have to be called before and after AddOne and RemoveOne. An exception should be raised if AddOne or RemoveOne is called outside of the Begin-End scope.

I ran into this same problem and created a helper class that looks like this:
public class BusyLock : IDisposable
{
private readonly Object _lockObject = new Object();
private int _lockCount;
public bool IsBusy
{
get { return _lockCount > 0; }
}
public IDisposable Enter()
{
if (!Monitor.TryEnter(_lockObject, TimeSpan.FromSeconds(1.0)))
throw new InvalidOperationException("Cannot begin operation as system is already busy");
Interlocked.Increment(ref _lockCount);
return this;
}
public bool TryEnter(out IDisposable busyLock)
{
if (Monitor.TryEnter(_lockObject))
{
busyLock = this;
Interlocked.Increment(ref _lockCount);
return true;
}
busyLock = null;
return false;
}
#region IDisposable Members
public void Dispose()
{
if (_lockCount > 0)
{
Monitor.Exit(_lockObject);
Interlocked.Decrement(ref _lockCount);
}
}
#endregion
}
You can then create an instance wrapped like this:
public sealed class AutomationManager
{
private readonly BusyLock _automationLock = new BusyLock();
public IDisposable AutomationLock
{
get { return _automationLock.Enter(); }
}
public bool IsBusy
{
get { return _automationLock.IsBusy; }
}
}
And use it like this:
public void DoSomething()
{
using (AutomationLock)
{
//Do important busy stuff here
}
}
For my particular case, I only wanted an enforcing lock (two threads shouldn't ever try to acquire the lock at the same time if they're well-behaved), so I throw an exception. You can easily modify it to perform more typical locking and still take advantage of the IsBusy.