问题
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
}
回答1:
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.
- 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.
- 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
回答2:
I just found LazyCache lib. I haven't tried it yet in production though.
IAppCache cache = new CachingService();
ComplexObject cachedResults = cache.GetOrAdd("uniqueKey",
() => methodThatTakesTimeOrResources());
回答3:
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.
来源:https://stackoverflow.com/questions/10714790/how-can-i-lock-by-cache-key