[Haskell-cafe] Fwd: Timing and Atom

Lee Pike leepike at gmail.com
Tue Dec 1 11:43:00 EST 2009


[Tom -- resending my reply---I forgot to post to the list.]

Neil, could you provide a reference (more on the practical side than  
the theory side) for the Stochastic Process Algebras you mention?  And  
is there an embedding in Haskell? :)

Lee


Begin forwarded message:

From: Lee Pike <leepike at gmail.com>
Date: November 30, 2009 10:14:33 PM PST
To: Tom Hawkins <tomahawkins at gmail.com>
Subject: Re: Timing and Atom

Tom,

Thanks a lot for the detailed reply!

> If you need greater timing resolution than what is provided by the
> main loop, then I think the only option is to reference a hardware
> counter.

Right, of course. Use a hardware counter if you're not using a RTOS.   
That was the quick answer I wasn't considering. :)

> I never considered running Atom generated functions in an asynchronous
> loop until you posted your "Atomic Fibonacci Server" example

Yeah, I always think it's fun to use synchronous languages  
asynchronously.  Usually people think of trying to implement synchrony  
from asynchronous languages.

> But there is a wide field of applications where this approach would  
> work just
> fine -- not having to worry about meeting a hard loop time would
> certainly simplify the design.

I think it's a trade-off, right?  You don't worry as much about time,  
but you have to worry about doing synchronization using handshakes or  
similar protocols.  I know folks who make fault-tolerant systems  
generally prefer synchronized systems since asynchrony gets really  
hard once you start considering the possibility of random faults (See,  
for example, <http://embedded.eecs.berkeley.edu/giotto/> or _Real-Time  
Systems_ by Hermann Kopetz).

> Could some form of static analysis be applied to provide the timing  
> guarantees?

Of the asynchronous system (e.g., the "Fib. server")?  In something  
like that, it should function under any possible schedule because of  
the handshakes (I should model-check it to prove that).  Did I  
misunderstand your point?

Thanks again for answering my question!

Lee




More information about the Haskell-Cafe mailing list