Date: 05 Nov 1999 19:16:35 +0000 From: Randell Jesup <rjesup@wgate.com> To: arch@freebsd.org Subject: Re: FSM's Message-ID: <ybuaeospx4c.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Amancio Hasty's message of "Fri, 05 Nov 1999 13:05:55 -0800" References: <199911052105.NAA57850@rah.star-gate.com>
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.
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.
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).
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".
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.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?ybuaeospx4c.fsf>