22

I am trying to implement a generic thread-safe Cache method, and I wonder how I should implement the lock in it.

It should look something like this:

//private static readonly lockObject = new Object();

public T GetCache<T>(string key, Func<T> valueFactory...)
{

  // try to pull from cache here

  lock (lockObject) // I don't want to use static object lock here because then every time a lock is performed, all cached objects in my site have to wait, regarding of the cache key.
  {
    // cache was empty before we got the lock, check again inside the lock

    // cache is still empty, so retreive the value here

    // store the value in the cache here
  }

  // return the cached value here

}
wonea
  • 4,783
  • 17
  • 86
  • 139
Amir
  • 589
  • 1
  • 5
  • 18
  • What are you trying to achieve? it seems to me that you are confusing between 2 types of locks: lock to ensure only one thread can edit the cached object and a lock to ensure adding/removing from the cache is thread safe. Adding a lock per object will help u to make sure only one thread can change it, but it has nothing to do with with adding/removing it from the cache (which implementation you didnt provide, but im guessing its going to be some kind of dictionary). I dont think you can dismiss the cache - collection level lock anyway. – YavgenyP May 23 '12 at 07:03
  • I am using Asp.net cache... so I don't have to implement my own dictionary... And i am talking about locking for adding... Let's say 1000 people requested the page at the same time, I want only one them of them to cache to object, and all the others to use it... – Amir May 23 '12 at 07:07
  • you still need to lock the underlying collection, and not the object. what you want to do, if i understand correctly, is to check if the object is not present in this collection, and only then add it. If you are using .net 4, you can use one of their new blocking collections, such as ConcurrentDictionary to make sure each key is added only once. – YavgenyP May 23 '12 at 07:18

3 Answers3

7

For non shared data among pools

When you have many pools (web garden) each pool can have their static data. There I have measure this days that the ConcurrentDictionary<TKey, TItem> is the faster because they have implement some kind of technique that don't use look inside, so they have make it extreme fast.

So I suggest the ConcurrentDictionary<TKey, TItem> for non shared data among pools.

In this case you must take care the synchronization of the data him self to avoid concurrent data change on the same the data. There you can use the SlimLock, or a Lock.

common resources change among pools

Now, when you have resource that are shared among pools, you need to use mutex. For example if you try to go to save a file from many threads, of open a file for change it from many threads - you need mutex to synchronize that common resource

So for common resource you use the mutex
Mutex can use a Key to lock to lock base on that key - but you can not change the same resource!.

public T GetCache<T>(string key, Func<T> valueFactory...) 
{
    // 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
    }
    finally
    {
        // Release the Mutex.
        mut.ReleaseMutex();
    }   
}

What kind of lock

we have two case for lock.

  1. One case is when we use common resources in all pools, all threads. Common resource can be a file, or the database its self.

In the common resources we need to use mutex.

  1. Second case is when we use variables that are visible only to the inside of a pool - different pools can not see that resources. For example a static List<>, a static Dictionary etc. This static variables, arrays can access only inside the pool and they are not the same across different pools.

In this second case, the lock() is the most easy and common way to use.

Faster than lock

Now, when we have a static dictionary that we keep for long time and make too many reads/writes there, a faster approach to avoid the full program to wait, is the ReaderWriterLockSlim

you can take a full example from here: ReaderWriterLockSlim

Using the ReaderWriterLockSlim, we can avoid the locks when we do not need them - and we do not need to lock the static values when we read - only when we write on them. So I can suggest it for static values that we use them as cache.

What is a pool in asp.net.

Imaging as if different programs that run isolate each other but serves the incoming requests from users. Each pool have his own world and they are not communicate each other. Each pool have their initialize, their static values, and their life. To have some common resource between pools you need some other third program, like a database, like a file on disk, like a service.

So if you have many pools (web garden) to synchronize them for common resource you need mutex. To synchronize them inside you use lock.

IIS app pools, worker processes, app domains
Lifetime of ASP.NET Static Variable

Aristos
  • 66,005
  • 16
  • 114
  • 150
  • Even if he needs a lock or sync object of any kind - why should he use mutex and not monitor? " The Mutex class uses more system resources than the Monitor class" (from [msdn](http://msdn.microsoft.com/en-us/library/hw29w7t1.aspx)) – YavgenyP May 23 '12 at 08:26
  • 1
    @YavgenyP there are two main reasons: 1) for lock all threads that go to use/make this cache, and only one thread. 2) To give name and lock only this same part of cache and not every cache that is requested. - Now, I do not know if he needs or not sync, I replay to him hot to do it and not argue if he needed or not. – Aristos May 23 '12 at 08:54
3

I just found LazyCache lib. I haven't tried it yet in production though.

IAppCache cache = new CachingService();
ComplexObject cachedResults = cache.GetOrAdd("uniqueKey", 
    () => methodThatTakesTimeOrResources());
Stanislav
  • 4,389
  • 2
  • 33
  • 35
0

The .NET ConcurrentDictionary<TKey, TItem> implements this internally by creating a separate lock for each key hash. This has the benefit of only locking the one relevant hash, even when processing item additions and removals.

shannon
  • 8,664
  • 5
  • 44
  • 74