From owner-freebsd-arch Fri Nov 5 13: 8:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3415314D64 for ; Fri, 5 Nov 1999 13:08:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA24188 for ; Fri, 5 Nov 1999 22:07:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA01159 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 22:07:20 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 8DBEE14D64 for ; Fri, 5 Nov 1999 13:07:03 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id NAA57850; Fri, 5 Nov 1999 13:05:55 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911052105.NAA57850@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Randell Jesup Cc: arch@freebsd.org Subject: Re: FSM's In-reply-to: Your message of "05 Nov 1999 16:00:34 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Nov 1999 13:05:55 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Peter Jeremy 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