What are we going to do tomorrow night, Brain? - All Comments

I don’t have the mental capacity to understand « Malaysian's Chromosome

I don’t have the mental capacity to understand « Malaysian's Chromosome — Fri, 05 Mar 2010 08:56:30 GMT

Pingback from I don’t have the mental capacity to understand « Malaysian's Chromosome

WPF for the Web guy

mostlylucid — Wed, 20 Jan 2010 21:01:59 GMT

WPF for the Web guy

Twitter Trackbacks for Thread Safe Dictionary in .NET with ReaderWriterLockSlim - What are we going to do tomorrow night, Brain? [dotnetcommandos.com] on Topsy.com

Thu, 07 Jan 2010 21:46:33 GMT

Pingback from Twitter Trackbacks for Thread Safe Dictionary in .NET with ReaderWriterLockSlim - What are we going to do tomorrow night, Brain? [dotnetcommandos.com] on Topsy.com

re: Thread Safe Dictionary Update

dj_axl — Wed, 21 Oct 2009 22:05:49 GMT

And to add to PeterZacho's post...

public ThreadSafeDictionary(IDictionary<TKey, TValue> dic)

{

using (new WriteLock(this.dictionaryLock))

{

this.dict = new Dictionary<TKey, TValue>(dic);

}

re: Thread Safe Dictionary Update

dj_axl — Wed, 21 Oct 2009 20:21:48 GMT

For my use needed to add a cast...

public static implicit operator Dictionary<TKey, TValue>(ThreadSafeDictionary<TKey, TValue> tsd)

{

using (new ReadOnlyLock(tsd.dictionaryLock))

{

return (Dictionary<TKey, TValue>)tsd.dict;

}

蛙蛙推荐：设计一个高效的网络服务器用户管理类

蛙蛙池塘 — Fri, 10 Apr 2009 16:39:10 GMT

摘要：做一个有状态的网络服务端应用，一般需要维护一个在线用户列表，每次用户登录、注销都要修改这个列表，还得考虑超时清理的逻辑，对这个列表的操作大多时候需要用锁来进行线程同步，我们试图来用一种不需要线程同步的方法来做到这些事情。

re: Thread Safe Dictionary Update

Brian Rudolph — Mon, 23 Mar 2009 14:45:11 GMT

I have done some scale testing in a few isolated situations.

In general, this solution is at least as fast as one using monitor with a small number of threads.

When I run it in some larger environments, like our inbound or outbound xml feed processors and caching models, where we have lots of threads, this model easily wins. I have seen read\write performance increases of 80%+ when we have a dozen or more threads working concurrently. These are situations where our servers would sit reasonably idle due to read\write contention. Now we can easily spin them up to 95%+ active.

As always, individual testing is important.

re: Thread Safe Dictionary Update

Alpha — Thu, 19 Mar 2009 12:24:33 GMT

Have you done any performance/scalability tests of this?

When I look at the code it seems that the only methods that gain anything compared to a solution that just use a Monitor are CopyTo, Values and Keys (this is the methods that actually may hold the read lock for long periods) - and only if the dictionary contains a significant number of elements.

The reason is that acquiring a ReaderWriteLockSlim is about 50% more expensive than acquiring a Monitor. In addition a simple dictionary operation (e.g. TryLookup, Add, and Remove) only cost about 25-50% of acquiring a Monitor.

MSCS Clusters, iSCSI, Distance Clusters and SQL 2005

RTFM. Especially if you can't figure it out on your own! — Sat, 07 Mar 2009 05:51:22 GMT

This has been a fun week with clustering. Myself and a few others have been working this week on setting

re: Thread Safe Dictionary Update

Brian Rudolph — Sat, 14 Feb 2009 22:02:03 GMT

The problem with what you say about acquiring the read lock, and then releasing it before acquiring the write lock is simply because it opens the door for someone to insert the same value you are trying to insert before you acquire the write lock. This would cause a duplicate key conflict and subsequent error.

This is exactly the scenario that upgradeable read locks were designed for. That is because noone can acquire a write lock before i've released my read lock. Also, only one upgradeable lock can be held at a time, which prevents two threads waiting for a write lock while already holding an upgradeable read.

I believe this is a fundamentally important feature in readerwriterlockslim.

re: Thread Safe Dictionary Update

FrankB — Fri, 02 Jan 2009 11:15:55 GMT

Hi Brain, can you explain why you are dooing a Busy-wait when acquiring a lock (the while loops)? This seems to be quite expensive.

I also noticed that you used the upgradable read lock when dooing double check locking. While this is better than directly getting a Write lock, I would do the first check with just a read lock, release the read lock, and then acquire the write lock to do the update. This allows for better concurrency without casing deadlocks.

You might also want to check out what microsoft is doing in PFX, I wrote a blog about their ConcurrentDictionay last week blogs.infosupport.com/.../Implementing-a-Thread-Safe-cache-using-the-Parallel-Extensions.aspx

re: Thread Safe Dictionary Update

PeterZacho — Sun, 28 Dec 2008 07:21:16 GMT

Thanks for the code, Brian. While using it I realized that a couple of constructors are missing - the following changes helped me:

//This is the internal dictionary that we are wrapping

IDictionary<TKey, TValue> dict;

[NonSerialized]

ReaderWriterLockSlim dictionaryLock = Locks.GetLockInstance(LockRecursionPolicy.NoRecursion); //setup the lock;

public ThreadSafeDictionary()

{

dict = new Dictionary<TKey, TValue>();

}

public ThreadSafeDictionary(int capacity)

{

dict = new Dictionary<TKey, TValue>(capacity);

}

public ThreadSafeDictionary(ThreadSafeDictionary<TKey, TValue> original)

{

dict = new Dictionary<TKey, TValue>(original.dict);

}

re: Thread Safe Dictionary Update

Brian Rudolph — Wed, 26 Nov 2008 19:47:23 GMT

Interesting observations. The recursion issue i had already dealt with but had not posted. The Serialization issue I had not run across. I failed to recognize that the default constructor would not be called on binary deserialization.

I have posted the updates. Thanks for the feedback.

re: Thread Safe Dictionary Update

mnero0429 — Thu, 20 Nov 2008 19:45:46 GMT

There's a problem with this implementation in that it claims that it is serializable. If the object is serialized, it looses its ReaderWriterLockSlim instance once it is deserialized. Upon deserialization, you'll start to encounter NullReferenceExcpetions when you call methods.

Also, do you have a test instance that requires the ReaderWriterLockSlim instance to support lock recursion? I couldn't find any reason for this in your implementation of ThreadSafeDictionary.

re: Thread Safe Dictionary Update

David Justice — Mon, 03 Nov 2008 19:17:18 GMT