Permalink
Browse files

read lock is not required when writeLock is taken, since we know anot…

…her write can't be concurrently happening (thanks to @pchapuis for pointing this out)
  • Loading branch information...
1 parent 3dcce95 commit 7e667be825f4b99355a428dfd333b80e46dac0f2 Karl Seguin committed Nov 20, 2013
Showing with 1 addition and 3 deletions.
  1. +1 −3 _posts/2013-11-20-Concurrent-Reads-With-Serialized-Writes.html
@@ -71,11 +71,9 @@
writeLock.Lock()
defer writeLock.Unlock()
- lock.RLock()
l := len(values)
newValues := make([]string, l+1)
copy(newValues, values)
- lock.RUnlock()
newValues[l] = value
@@ -87,4 +85,4 @@
<p>The new lock ensures that writes are serialized, so that one won't stomp another. With this new guardian in place, we can safely use our main lock more finely, allowing concurrent reads even during the slow part (in this case <code>copy</code>) of our write.</p>
-<p>This won't always work. It depends what your write is doing. But I'm rather fond of the approach.</p>
+<p>This won't always work. It depends what your write is doing. But I'm rather fond of the approach. (Thanks to <a href="http://www.twitter.com/pchapuis">@pchapuis</a> for further reducing the amount of locking required.)</p>

0 comments on commit 7e667be

Please sign in to comment.