[web-devel] Caching the System time

[Gregory Collins]

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

    http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L1440

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

    atomicModifyMutVar#:
http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L253

and

    readMutVar# / writeMutVar#:
http://hackage.haskell.org/trac/ghc/browser/compiler/codeGen/CgPrimOp.hs#L128

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.

G

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>