Date: Fri, 05 Nov 1999 15:36:43 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: Randell Jesup <rjesup@wgate.com> Cc: arch@freebsd.org Subject: Re: FSM's Message-ID: <199911052336.PAA58947@rah.star-gate.com> In-Reply-To: Your message of "05 Nov 1999 19:16:35 GMT." <ybuaeospx4c.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Amancio Hasty <hasty@rah.star-gate.com> writes:
> >1. Both FSM and Posix thread have locking problems.
> >
> > If you are in a state and need to access a data region which is
> > shared by several states you may need to lock the data region.
>
> True.
>
> >2. FSMs with gotos are not linear. For instance for a multi connection
> >server you can serve concurrent connections which I did for an FTAM
> >file server.
> >
> >I implemented FTAM (ISO) as a FSM on VMS a decade ago for Touch
> >Communications. The ISO Session layer specification came with its own
> >FSM which the engineer at Touch implemented. Again this was for a multi
> >connection server.
>
> Of course, FSM's can be 'multitasking'/multithreaded - the old
> PlayNet software I wrote for C64's (later ported to the PC as America
> Online) used a 'multitasking' FSM (with state pushes/pops as well) to
> handle chat, Online (Instant) Messages, menus, etc. This certainly works;
> the only problem is that this assumes that either (a) the time to handle an
> input is shorter than the time between inputs, or (b) responsiveness to an
> input doesn't need to be better than the maximum time to handle an input.
> You do get 'free' implicit locking of datastructures while handling a
> (single) input.
>
> There are also issues of shared context, such as the current
> directory.
Which is why you need locking.
> In theory, you could call a multitasking (but non-pre-emptive) OS
> basically the same thing as a really big FSM. Not that this tells you
> very much useful.
Well, Von Neumann second computer architecture was an FSM machine
to attempt to model the human brain 8)
> I simply find it _far_ easier to work in the paradigm of
> multitasking, messages, and queues than FSMs. Sometimes FSMs are fine (a
> lot of windowing events can be handled in a Mac/Windows/Amiga/X-style event
> loop). Sometimes they're not - a lot of X apps freeze and don't even
> refresh or let the UI work if a system call hasn't returned, because their
> UI handling is part of their program (via toolkits).
I think that this is an implementation issue : A few years ago I interviewed
over the phone for an X server position at Sun.
Top X server from Sun: What do you think X needs
Amancio: How about tracing so programmers can have
and easier time debugging X applications?
Top X server: Do you really think that programmers need
tracing?
At Touch we didn't have problems tracking down FSM states .
> However, we're wandering far afield here (sorry) - the question
> isn't "are threads useful" - they are. The question is "how do we
> implement them".
As an FSM of course , I thought that was clear 8)
--
Amancio Hasty
hasty@rah.star-gate.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911052336.PAA58947>