[web-devel] Caching the System time

Gregory Collins greg at gregorycollins.net
Mon Aug 8 14:24:28 CEST 2011

Not really. tryTakeMVar and tryPutMVar are pretty heavyweight and involve
taking a mutex lock:


IORef is much lighter-weight, see e.g.



    readMutVar# / writeMutVar#:

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).

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.


On Sun, Aug 7, 2011 at 12:20 AM, Greg Weber <greg at gregweber.info> wrote:

> couldn't tryTakeMVar and tryPutMVar handle this case of multiple writers
> well? I am asking because I really don't know :)
> On Sat, Aug 6, 2011 at 2:05 PM, Gregory Collins <greg at gregorycollins.net>wrote:
>> On Sat, Aug 6, 2011 at 8:11 PM, Michael Snoyman <michael at snoyman.com>wrote:
>>> Without having delved into the issue in any great depth, I had a
>>> possible idea on this point. How about storing an IORef containing a
>>> time and the text representations you need. Whenever you need to get
>>> the time, compare the time in the IORef with the current time, and if
>>> they're different, update appropriately. Bonus points: store in an
>>> unpacked datatype and use a Builder instead of String. Would this (in
>>> theory) work?
>> 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.
>> G
>> --
>> Gregory Collins <greg at gregorycollins.net>
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel

Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110808/f68e2daa/attachment.htm>

More information about the web-devel mailing list