<?xml version="1.0" encoding="UTF-8"?><rss
version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
> <channel><title>Comments on: Playing with a few ReaderWriterLocks in .Net</title> <atom:link href="http://ripper234.com/p/playing-with-a-few-readerwriterlocks-in-net/feed/" rel="self" type="application/rss+xml" /><link>http://ripper234.com/p/playing-with-a-few-readerwriterlocks-in-net/</link> <description>Stuff Ron Gross Finds Interesting</description> <lastBuildDate>Fri, 27 Jan 2012 03:20:29 +0000</lastBuildDate> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.3.1</generator> <item><title>By: ripper234</title><link>http://ripper234.com/p/playing-with-a-few-readerwriterlocks-in-net/comment-page-1/#comment-2195</link> <dc:creator>ripper234</dc:creator> <pubDate>Tue, 11 May 2010 05:38:44 +0000</pubDate> <guid
isPermaLink="false">http://ripper234.com/?p=907#comment-2195</guid> <description>@Eli, I measured how long the test takes to run. While I forgot to attach the test code here, it basically spun a few concurrent reader/writer threads that all had contention on a single lock. They did a very small amount of work inside that lock, then gave it up. If I remember correctly, I had a fixed ratio of readers vs writers. Increasing the number of threads in this case increases the runtime because there is actually more work to do.
In this case I simply wanted to see how well the lock performs under extreme contention. It is not &quot;realistic&quot; - you&#039;d need to think more thoroughly about what exactly you&#039;re trying to measure to get more meaningful results - but even this simplistic testing was interesting in that it exposes differences between the different implementations.
Looking forward to your post on RW locks.</description> <content:encoded><![CDATA[<p>@Eli, I measured how long the test takes to run. While I forgot to attach the test code here, it basically spun a few concurrent reader/writer threads that all had contention on a single lock. They did a very small amount of work inside that lock, then gave it up. If I remember correctly, I had a fixed ratio of readers vs writers. Increasing the number of threads in this case increases the runtime because there is actually more work to do.</p><p>In this case I simply wanted to see how well the lock performs under extreme contention. It is not &#8220;realistic&#8221; &#8211; you&#8217;d need to think more thoroughly about what exactly you&#8217;re trying to measure to get more meaningful results &#8211; but even this simplistic testing was interesting in that it exposes differences between the different implementations.</p><p>Looking forward to your post on RW locks.</p> ]]></content:encoded> </item> <item><title>By: Eli</title><link>http://ripper234.com/p/playing-with-a-few-readerwriterlocks-in-net/comment-page-1/#comment-2194</link> <dc:creator>Eli</dc:creator> <pubDate>Tue, 11 May 2010 04:16:22 +0000</pubDate> <guid
isPermaLink="false">http://ripper234.com/?p=907#comment-2194</guid> <description>Ron,
Nice writeup - I recently looked into RW locks, recalled that you once wrote about it and came back to read it. I&#039;m not sure I understand your performance graph - what are you measuring exactly? Also, are you really creating that many threads - and if so, is it really realistic, or would a better benchmark involve a realistic amount of threads with a vertical load (i.e. large amount of read and write operations to perform)?</description> <content:encoded><![CDATA[<p>Ron,</p><p>Nice writeup &#8211; I recently looked into RW locks, recalled that you once wrote about it and came back to read it. I&#8217;m not sure I understand your performance graph &#8211; what are you measuring exactly? Also, are you really creating that many threads &#8211; and if so, is it really realistic, or would a better benchmark involve a realistic amount of threads with a vertical load (i.e. large amount of read and write operations to perform)?</p> ]]></content:encoded> </item> </channel> </rss>
