Christopher Smith wrote:
Andrew Lentvorski wrote:
The big problem is that time is a variable in our systems, *and we
don't account for it*. In spite of its best efforts, asynchronous
logic *still* hasn't made significant penetration into VLSI design
because it suffers from all the same problems that software does.
Consequently, everybody in VLSI still pretty much relies on a global
clock to lock everything together.
If you look at how concurrency is handled in Erlang and Haskell, you'll
have a better understanding of how managing "state" and managing "time"
are really two sides of the same coin. Time only matters when there are
changes of state.
Sorta.
Erlang handles it a couple of ways:
First, nothing may be shared. All communication is by messages that are
copied. This has interesting performance tradeoffs. There is a
comparison between Gambit/Termite and Erlang where you see that Erlang
benefits as long as the messages are small and starts to die when the
messages get big--Gambit/Termite is the reverse.
Second, it puts watchdogs over things and if they lock, it kills and
restarts them. That solves the *symptom*, but not the problem.
Third, all messages are received asynchronously, so you have to account
for that outright in your coding style.
In fact, proper Erlang is really the only system I know of which does
handle state machines properly because *that's the way you have to write
your code*.
However, even Erlang still doesn't really have a notion of time. If you
need synchronous behavior (A must occur before B which must occur before
C), it's a real pain in Erlang.
Now, to be fair, getting it *correct* in other languages is a real pain,
too. Erlang just makes explicit the grief you have to go through.
However, this kind of grief is what I expect a compiler/language to take
care of for me.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
