[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
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