Not really. tryTakeMVar and tryPutMVar are pretty heavyweight and involve taking a mutex lock:<div><br></div><div> <a href="http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L1440">http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L1440</a><br>
<br></div><div>IORef is much lighter-weight, see e.g.</div><div><br></div><div> atomicModifyMutVar#: <a href="http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L253">http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L253</a></div>
<div><br></div><div>and</div><div><br></div><div> readMutVar# / writeMutVar#: <a href="http://hackage.haskell.org/trac/ghc/browser/compiler/codeGen/CgPrimOp.hs#L128">http://hackage.haskell.org/trac/ghc/browser/compiler/codeGen/CgPrimOp.hs#L128</a></div>
<div><br></div><div>The readMutVar primop just does a read (which turns into a small number of assembly instructions), and the writeMutVar primop just does a store and then marks the location dirty in the garbage collector. Doing an atomicModifyMutVar# involves a CAS which is also typically cheaper than mutex locking (you spin-loop instead of doing blocking/wakeup semantics).</div>
<div><br></div><div>For the Snap date-caching code, we only mess with mutex locks if the date thread has been idle for a couple of seconds, in which case we don't mind paying the overhead of doing the locking. It's the "X hundred/thousand QPS" case we're trying to optimize.</div>
<div><br></div><div>G</div><div><br></div><div><div class="gmail_quote">On Sun, Aug 7, 2011 at 12:20 AM, Greg Weber <span dir="ltr"><<a href="mailto:greg@gregweber.info">greg@gregweber.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>couldn't tryTakeMVar and tryPutMVar handle this case of multiple writers well? I am asking because I really don't know :)</div><div><br></div><div><div class="gmail_quote"><div><div></div><div class="h5">On Sat, Aug 6, 2011 at 2:05 PM, Gregory Collins <span dir="ltr"><<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5"><div>On Sat, Aug 6, 2011 at 8:11 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Without having delved into the issue in any great depth, I had a<br>
possible idea on this point. How about storing an IORef containing a<br>
time and the text representations you need. Whenever you need to get<br>
the time, compare the time in the IORef with the current time, and if<br>
they're different, update appropriately. Bonus points: store in an<br>
unpacked datatype and use a Builder instead of String. Would this (in<br>
theory) work?<br></blockquote></div><div><br>We do something similar to this, except we get the thread to recompute the date -- otherwise every second you have a race condition possibility where multiple threads compete to write the new thread into the IORef. If there's no activity, the date thread goes to sleep, the code to get the current date notices that the date is stale, and then it wakes the thread and recomputes the new date itself. Again, I'm not sure if it's worth it in the general case, but during periods of high load I think it helps to get as much stuff out of the processing threads as possible.<br>
<br>G<br></div></div><font color="#888888">-- <br></font><div><div></div><div>Gregory Collins <<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</a>><br>
</div></div><br></div></div><div class="im">_______________________________________________<br>
web-devel mailing list<br>
<a href="mailto:web-devel@haskell.org" target="_blank">web-devel@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/web-devel" target="_blank">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>Gregory Collins <<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</a>><br>
</div>