Date: Fri, 05 Nov 1999 13:05:55 -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: <199911052105.NAA57850@rah.star-gate.com> In-Reply-To: Your message of "05 Nov 1999 16:00:34 GMT." <ybuhfj1orml.fsf_-_@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> writes: > >>1) A means of allowing programmers to build procedural > >> soloutions instead of state machines. > >> > >> This is really a programmer convenience, for programmers > >> who know how to write linear code, but don't know how to > >> do finite state automata, > > > >I think that's being a bit unfair. > > > >One problem with FSA's is that following their internal logic can > >sometimes be substantially more difficult than following an equivalent > >linear control flow. This makes than more difficult to write and > >check - and increases the maintenance costs. > > FSM's also have the implicit assumption that inputs can be handled > in order of reception, and in a timely fashion. If some inputs need > quicker responses than the time to handle other inputs allows, FSM's have > a problem. This is one reason why threaded programs/OS's can have a very > snappy UI response 'feel' compared to single-threaded - the UI response > can run on a different thread than handling of the UI-invoked events. > This isn't even considering the issues of (long) blocking system calls, > which make it more of an issue. > > FSM's where there are a number of loosely related sets of states > can be very confusing as well. Threads mean you have to worry about > synchronization and locking. Oh well; every technique has plusses and > minuses. > > >>1) SMP scalability > > > >IMHO, this is going to rise in importance over time - and probably > >become the predominant reason for writing threaded code. It's > >becoming more and more difficult to make single processors faster, > >so fast machines will increasingly rely on multiple processors. > > This hasn't happened yet, though it's been predicted for a > decade or more - but I agree, it has to happen eventually. > > -- 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. 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. -- 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?199911052105.NAA57850>