I have a memory cached object-cache, said cache can hold multiple types, and i want to add a lock on said {T} whenever given {T} is accessed.
My implementation:
readonly static IDictionary<Type, List<object>> _cache = new ConcurrentDictionary<Type, List<object>>();
private static List<object> FindTypeInCache(Type type)
{
List<object> list;
if (_cache.TryGetValue(type, out list))
{
return list;
}
else
{
_cache[type] = new List<object>();
}
return new List<object>();
}
public static T FindFirstBy<T>(Func<T, bool> predicate) where T : class
{
// Is this a valid lock locking only _cache[T] ? And not _cache as whole?
lock (_cache[typeof(T)])
{
return FindTypeInCache(typeof(T)).Cast<T>().Where(predicate).FirstOrDefault();
}
}
public static bool AddOrUpdate<T>(Func<T, bool> predicate, T entity) where T : class
{
lock (_cache[typeof(T)])
{
// Find Type cache.
List<object> list = FindTypeInCache(typeof(T));
// Look for old entity.
var e = list.Cast<T>().Where(predicate).FirstOrDefault();
// If no old record exists no problem we treat this as if its a new record.
if (e != null)
{
// Old record found removing it.
list.Remove(e);
}
// Regardless if object existed or not we add it to our Cache.
list.Add(entity);
_cache[typeof(T)] = list;
}
}
Is my implementation correct only locking down _cache[T] and not entire _cache as a whole when accessed?
There's a lot of things weird (or outright wrong) with your code.
First, you're using a ConcurrentDictionary, but you're not using it as a concurrent dictionary. For example, to initialize the list, you'd use the GetOrAddMethod:
private static List<object> FindTypeInCache(Type type)
{
return _cache.GetOrAdd(type, () => new List<object>());
}
Simple and thread-safe :)
Second, you're locking on _cache[type] - but even when there's no such type in the cache. This means a KeyNotFoundException.
Third, the only code you're protecting with the lock is the reading. But that quite likely isn't enough - at the very least, you need to also protect the writing with the same lock (especially tricky given the point above), and depending on your actual usage of the return value, the return value's mutations (and if it is indeed mutable, any reads of that mutable value as well).
In other words, you've only managed to protect the code that doesn't actually need protecting (if you use the correct method to update the dictionary)! The extra lock around the Where etc. might help slightly, but it certainly doesn't make the List access safe.
All that said, maybe there's a better solution anyway. You're using the cache using generic methods. Why not make the cache itself generic? This way, you'll avoid using a dictionary in the first place, because each of the generic types you're storing in the dictionary will get their own type - it also means you can initialize the List<T> in a static constructor safely. Any locking can than also be safely applied to all access to a specific generic cache rather than the "aggregate" cache you have now.
Related
Does replacing a value associated with a ConcurrentDictionary key lock any dictionary operations beyond that key?
EDIT: For example, I'd like to know if either thread will ever block the other, besides when the keys are first added, in the following:
public static class Test {
private static ConcurrentDictionary<int, int> cd = new ConcurrentDictionary<int, int>();
public static Test() {
new Thread(UpdateItem1).Start();
new Thread(UpdateItem2).Start();
}
private static void UpdateItem1() {
while (true) cd[1] = 0;
}
private static void UpdateItem2() {
while (true) cd[2] = 0;
}
}
Initially I assumed it does, because for example dictionary[key] = value; could refer to a key that is not present yet. However, while working I realized that if an add is necessary it could occur after a separate lock escalation.
I was drafting the following class, but the indirection provided by the AccountCacheLock class is unnecessary if the answer to this question (above) is "no". In fact, all of my own lock management is pretty much unneeded.
// A flattened subset of repository user values that are referenced for every member page access
public class AccountCache {
// The AccountCacheLock wrapper allows the AccountCache item to be updated in a locally-confined account-specific lock.
// Otherwise, one of the following would be necessary:
// Replace a ConcurrentDictionary item, requiring a lock on the ConcurrentDictionary object (unless the ConcurrentDictionary internally implements similar indirection)
// Update the contents of the AccountCache item, requiring either a copy to be returned or the lock to wrap the caller's use of it.
private static readonly ConcurrentDictionary<int, AccountCacheLock> dictionary = new ConcurrentDictionary<int, AccountCacheLock>();
public static AccountCache Get(int accountId, SiteEntities refreshSource) {
AccountCacheLock accountCacheLock = dictionary.GetOrAdd(accountId, k => new AccountCacheLock());
AccountCache accountCache;
lock (accountCacheLock) {
accountCache = accountCacheLock.AccountCache;
}
if (accountCache == null || accountCache.ExpiresOn < DateTime.UtcNow) {
accountCache = new AccountCache(refreshSource.Accounts.Single(a => a.Id == accountId));
lock (accountCacheLock) {
accountCacheLock.AccountCache = accountCache;
}
}
return accountCache;
}
public static void Invalidate(int accountId) {
// TODO
}
private AccountCache(Account account) {
ExpiresOn = DateTime.UtcNow.AddHours(1);
Status = account.Status;
CommunityRole = account.CommunityRole;
Email = account.Email;
}
public readonly DateTime ExpiresOn;
public readonly AccountStates Status;
public readonly CommunityRoles CommunityRole;
public readonly string Email;
private class AccountCacheLock {
public AccountCache AccountCache;
}
}
Side question: is there something in the ASP.NET framework that already does this?
You don't need to be doing any locks. The ConcurrentDictionary should handle that pretty well.
Side question: is there something in the ASP.NET framework that already does this?
Of course. It's not specifically related to ASP.NET but you may take a look at the System.Runtime.Caching namespace and more specifically the MemoryCache class. It adds things like expiration and callbacks on the top of a thread safe hashtable.
I don't quite understand the purpose of the AccountCache you have shown in your updated answer. It's exactly what a simple caching layer gives you for free.
Obviously if you intend to be running your ASP.NET application in a web farm you should consider some distributed caching such as memcached for example. There are .NET implementations of the ObjectCache class on top of the memcached protocol.
I also wanted to note that I took a cursory peek inside ConcurrentDictionary, and it looks like item replacements are locked on neither the individual item nor the entire dictionary, but rather the hash of the item (i.e. a lock object associated with a dictionary "bucket"). It seems to be designed so that an initial introduction of a key also does not lock the entire dictionary, provided the dictionary need not be resized. I believe this also means that two updates can occur simultaneously provided they don't produce matching hashes.
I have a few library utilities which make things a little simpler.
public static RequestUow Uow
{
get { return ContextItemsHelper.Get<RequestUow>("Uow"); }
set { ContextItemsHelper.Set<RequestUow>("Uow", value); }
}
And in ContextItemsHelper
public static T Get<T>(string key)
{
Guard.NullOrEmpty(key, "key");
object obj = Items[key];
return obj.IsNotNull() ? (T)obj : default(T);
}
static IDictionary Items { get { return HttpContextHelper.Current.Items; } }
This works fine but i now want to check if the property uow is null, if it is set a new RequestUow and return it.
The examples I've seen involve setting your own member variable, however i'm wondering if this is likely to be threadsafe.
Anyone got any advice or solutions to offer?
Make Items a ConcurrentDictionary and use it's AddOrUpdate method. As the collection itself is thread safe, you won't have to care about it.
It would also be better if yourGet changed to something like this:
public static T Get<T>(string key)
{
Guard.NullOrEmpty(key, "key");
return Items.GetOrAdd( key, (key) => default(T) );
}
This way the defaults are added at first try and just returned if they are called again.
use pattern Double checked locking pattern
As long as the dictionary doesn't mutate (e.g. no updates), access it is fully threadsafe without any additional measures (*).
Note that it doesn't help to have threadsafe getter/setters for the dictionary if the items contained aren't threadsafe themselves. The safest bet is to use immutable items in the dictionary; if your RequestUow objects are mutable, then you need to make them (and everything else that might be retrieved using this dictionary) threadsafe as well.
*: See for instance this PDF for information on thread-safe collections in .NET. Page 18 clarifies that read-only access does not need additional measured for thread safety.
I have a list that is accessed by multiple background threads to update/read. Updates actions include both insertions and deletions.
To do this concurrently without synchronization problems, I am using a lock on a private readonly object in the class.
To minimize the time I need to lock the list when reading its data, I do a deep clone of it and return the deep clone and unlock the dictionary for insert/delete updates.
Due to this every read of the list increases the memory consumption of my service.
One point to note is that the inserts/deletes are internal to the class that contains the list. But the read is meant for public consumption.
My question is:
Is there any way, I can avoid cloning the list and still use it concurrently for reads using read/write locks?
public class ServiceCache
{
private static List<Users> activeUsers;
private static readonly object lockObject = new object();
private static ServiceCache instance = new ServiceCache();
public static ServiceCache Instance
{
get
{
return instance;
}
}
private void AddUser(User newUser)
{
lock (lockObject)
{
//... add user logic
}
}
private void RemoveUser(User currentUser)
{
lock (lockObject)
{
//... remove user logic
}
}
public List<Users> ActiveUsers
{
get
{
lock (lockObject)
{
//The cache returns deep copies of the users it holds, not links to the actual data.
return activeUsers.Select(au => au.DeepCopy()).ToList();
}
}
}
}
It sounds like you need to use the ConcurrentDictionary class, and create a key for each of the Users objects you are storing. Then it becomes as simple as this for adding / updating a user:
_dictionary.AddOrUpdate("key", (k, v) =>
{
return newUser;
}, (k, v) =>
{
return newUser;
});
And then for removing, you would do this:
Users value = null;
_dictionary.TryRemove("key", out value);
Getting the list of people would be super easy as well, since you would just need to do:
return _dictionary.Values.Select(x => x.Value).ToList();
Which should return a copy of the dictionary contents at that very moment.
And let the .NET runtime take care of the threading for you.
You can use a reader-writer lock to allow simultaneous reads.
However, it would be much faster to use a ConcurrentDictionary and thread-safe immutable values, then get rid of all synchronization.
Due to this every read of the list increases the memory consumption of
my service.
Why? Are the callers not releasing the reference? They need to, since the content of the dictionary can change.
What you are doing with copying is I think very close to how a Concurrent data structure, e.g. copy-on-write collection works, except that the caller cannot hold on to the reference.
A couple of other approaches:
Return the same copy to all callers till the collection gets modified. The returned collection should be immutable
Expose all the functionality the caller would want from the copy and use a single lock to work with the original list
I have a Visual Studio 2008 C# .NET 3.5 project where I want to have a thread-safe pool of Foo objects.
public class FooPool
{
private object pool_lock_ = new object();
private Dictionary<int, Foo> foo_pool_ = new Dictionary<int, Foo>();
// ...
public void Add(Foo f)
{
lock (pool_lock_)
{
foo_pool_.Add(SomeFooDescriminator, f);
}
}
public Foo this[string key]
{
get { return foo_pool_[key]; }
set { lock (pool_lock_) { foo_pool_[key] = value; } }
}
public IEnumerable<Foo> Foos
{
get
{
lock (pool_lock_)
{
// is this thread-safe?
return foo_pool_.Select(x => x.Value);
}
}
}
}
Is the public IEnumerable<Foo> Foos { get; } function thread-safe? Or, do I need to clone the result and return a new list?
No, it isn't.
If another thread adds to the dictionary while your caller enumerates that, you'll get an error.
Instead, you can do:
lock (pool_lock_) {
return foo_pool.Values.ToList();
}
Is the IEnumerable<Foo> Foos { get; } function thread-safe?
No.
Or, do I need to clone the result and return a new list?
No, because that's not right either. A threadsafe method that gives the wrong answer is not very useful.
If you lock and make a copy then the thing you are returning is a snapshot of the past. The collection could be changed to be completely different the moment the lock is released. If you make this threadsafe by making a copy then you are now handing a bag full of lies to your caller.
When you are dealing with single-threaded code, a reasonable model is that everything is staying the same unless you take specific measures to change a thing. That is not a reasonable model in multi-threaded code. In multi-threaded code, you should assume the opposite: everything is constantly changing unless you take specific measures (such as a lock) to ensure that things are not changing. What is the good of handing out a sequence of Foos that describe the state of the world in the distant past, hundreds of nanoseconds ago? The entire world could be different in that amount of time.
It is not thread safe. You need to return ToList():
return foo_pool_.Select(x => x.Value).ToList();
Careful of deferred execution!
The fact is the actual code runs after the lock has exited.
// Don't do this
lock (pool_lock_)
{
return foo_pool_.Select(x => x.Value); // This only prepares the statement, does not run it
}
You may want to consider a SynchronizedCollection,
SynchronizedCollection Class
Provides a thread-safe collection that contains objects of a type specified by the generic parameter as elements.
http://msdn.microsoft.com/en-us/library/ms668265.aspx
If you'll lock on every read access you'll end with very bad performance. And in suggestions to use toList you'll also allocate memory every time.
If you using .NET 4 just use ConcurrentDictionary class from new thread safe collections. They will provide very fast (lock free) mechanisms for accessing data from multiple threads.
http://msdn.microsoft.com/en-us/library/dd997305.aspx
If you are using old .NET version I would suggest you to use for cycle with count variable instead of foreach it will work if you only add elements without removing them (as in your example)
I've a class that contains a static collection to store the logged-in users in an ASP.NET MVC application. I just want to know about the below code is thread-safe or not. Do I need to lock the code whenever I add or remove item to the onlineUsers collection.
public class OnlineUsers
{
private static List<string> onlineUsers = new List<string>();
public static EventHandler<string> OnUserAdded;
public static EventHandler<string> OnUserRemoved;
private OnlineUsers()
{
}
static OnlineUsers()
{
}
public static int NoOfOnlineUsers
{
get
{
return onlineUsers.Count;
}
}
public static List<string> GetUsers()
{
return onlineUsers;
}
public static void AddUser(string userName)
{
if (!onlineUsers.Contains(userName))
{
onlineUsers.Add(userName);
if (OnUserAdded != null)
OnUserAdded(null, userName);
}
}
public static void RemoveUser(string userName)
{
if (onlineUsers.Contains(userName))
{
onlineUsers.Remove(userName);
if (OnUserRemoved != null)
OnUserRemoved(null, userName);
}
}
}
That is absolutely not thread safe. Any time 2 threads are doing something (very common in a web application), chaos is possible - exceptions, or silent data loss.
Yes you need some kind of synchronization such as lock; and static is usually a very bad idea for data storage, IMO (unless treated very carefully and limited to things like configuration data).
Also - static events are notorious for a good way to keep object graphs alive unexpectedly. Treat those with caution too; if you subscribe once only, fine - but don't subscribe etc per request.
Also - it isn't just locking the operations, since this line:
return onlineUsers;
returns your list, now unprotected. all access to an item must be synchronized. Personally I'd return a copy, i.e.
lock(syncObj) {
return onlineUsers.ToArray();
}
Finally, returning a .Count from such can be confusing - as it is not guaranteed to still be Count at any point. It is informational at that point in time only.
Yes, you need to lock the onlineUsers to make that code threadsafe.
A few notes:
Using a HashSet<string> instead of the List<string> may be a good idea, since it is much more efficient for operations like this (Contains and Remove especially). This does not change anything on the locking requirements though.
You can declare a class as "static" if it has only static members.
Yes you do need to lock your code.
object padlock = new object
public bool Contains(T item)
{
lock (padlock)
{
return items.Contains(item);
}
}
Yes. You need to lock the collection before you read or write to the collection, since multiple users are potentially being added from different threadpool workers. You should probably also do it on the count as well, though if you're not concerned with 100% accuracy that may not be an issue.
As per Lucero's answer, you need to lock onlineUsers. Also be careful what will clients of your class do with the onlineUsers returned from GetUsers(). I suggest you change your interface - for example use IEnumerable<string> GetUsers() and make sure the lock is used in its implementation. Something like this:
public static IEnumerable<string> GetUsers() {
lock (...) {
foreach (var element in onlineUsers)
yield return element;
// We need foreach, just "return onlineUsers" would release the lock too early!
}
}
Note that this implementation can expose you to deadlocks if users try to call some other method of OnlineUsers that uses lock, while still iterating over the result of GetUsers().
That code it is not thread-safe per se.
I will not make any suggestions relative to your "design", since you didn't ask any. I'll assume you found good reasons for those static members and exposing your list's contents as you did.
However, if you want to make your code thread-safe, you should basically use a lock object to lock on, and wrap the contents of your methods with a lock statement:
private readonly object syncObject = new object();
void SomeMethod()
{
lock (this.syncObject)
{
// Work with your list here
}
}
Beware that those events being raised have the potential to hold the lock for an extended period of time, depending on what the delegates do.
You could omit the lock from the NoOfOnlineUsers property while declaring your list as volatile. However, if you want the Count value to persist for as long as you are using it at a certain moment, use a lock there, as well.
As others suggested here, exposing your list directly, even with a lock, will still pose a "threat" on it's contents. I would go with returning a copy (and that should fit most purposes) as Mark Gravell advised.
Now, since you said you are using this in an ASP.NET environment, it is worth saying that all local and member variables, as well as their member variables, if any, are thread safe.