Ayende @ Rahien

Andras Zoltan commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 18 Jan 2010 15:34:44 GMT

I use the same pattern with ReaderWriterLockSlim for exactly the same reasons as you give - in a situation where you have an operation that will read and [potentially] write a structure (caching dictionaries etc are a common situation), the upgradeable lock is nigh-on pointless because it effectively knocks out your parallelism if you have a lot of threads. I can also vouch for the fact that the performance of a pattern like this can be very, very good.

Indranil commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Tue, 05 Jan 2010 11:57:32 GMT

That should be Dictionary int , string

Indranil commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Tue, 05 Jan 2010 11:55:13 GMT

+1 for calling str.GetHashCode() outside of the locked region. Then you can just use Dictionary as your container. I found this nice comparision of Monitor vs RWLS [blogs.msdn.com/.../...m-with-readerwriterlock.aspx](http://blogs.msdn.com/pedram/archive/2007/10/07/a-performance-comparison-of-readerwriterlockslim-with-readerwriterlock.aspx) So I agree with Bruno if the cost of acquiring the RWLock maybe greater than the benefit it provides. As always only measuring can give the answer.

Jarek Kowalski [MS] commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 19:51:53 GMT

Ayende, that's only worth it only IF lock contention is the problem, which is really dependent on how you're using the code.

Ayende Rahien commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 19:05:32 GMT

tobi, this IS RWLS

tobi commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 19:02:30 GMT

You might want to look at ReaderWriterLockSlim which you can rip out with reflector or get from Joe Duffy's blog.

Ayende Rahien commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 17:32:26 GMT

Jarek, The question is, would it really be worth it vs. simply using RWL?

Jarek Kowalski [MS] commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 17:30:49 GMT

If lock contention is the problem, you can perhaps reduce it by introducing multiple dictionaries and multiple locks that guard them (one for each dictionary). You can choose the dictionary to use based on something that's easy to compute lock-free (such as the length of the string or a hash of first few characters). Depending on your input data, degree of parallelism and contention, this may give you a nice boost, but YMMV.

Bruno Martinez commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 16:41:13 GMT

I'm not sure what's the cutting point, but given a sufficiently small critical section, a simpler synchronization primitive will be faster than a smarter one. I don't think you will see contention in this code. On a related note, I think I read somewhere that the hash of strings was cached. It may pay off to invoke str.GetHashCode() before acquiring the lock.

Ayende Rahien commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 16:30:17 GMT

Bruno, Not locking is better than locking. Even brief pauses can significantly slow down an app, if contention happens frequently enough

Bruno Martinez commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 16:26:11 GMT

Ayende, Yes, but unless I misunderstand the code, each thread holds the lock briefly enough to make the costs of the synchronization primitive dominant.

Ayende Rahien commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 15:48:14 GMT

Bruno, Monitor would force a single thread in the read mode as well, which is bad.

Bruno Martínez commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 15:44:47 GMT

My guess is that a simple Monitor would be faster than any complex read/write lock.

Smith commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 14:05:15 GMT

Why you didn't used the ReaderWriterLock.UpgradeToWriterLock method?

configurator commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 13:55:37 GMT

toby, If I understand it correctly, it's use is if you have EnterUpgradeableReadLock with EnterReadLock - an upgradable lock and many read locks can be entered at the same time. Then, when you upgrade, it waits for all the reads to finish. I do find the API quite weird. It would make a little more sense to have it as locker.EnterUpgradeableReadLock(); try { .... locker.UpgradeLock(); .... } finally { locker.ExitUpgradeableLock(); } But I guess there are some problems with that API that I haven't thought of.

Ayende Rahien commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 13:14:26 GMT

It isn't really that useful, I would say. The places where you can make good use of it are VERY rare, and it is more likely to do harm than good.

tobi commented on Using ReaderWriterLockSlim’s EnterUpgradeableReadLock

Mon, 04 Jan 2010 13:07:34 GMT

what use is EnterUpgradeableReadLock then? You could just always use a write lock as it seems to have the same effect from your description. In both cases only one thread can enter.