From owner-freebsd-arch Fri Nov 5 12: 6:30 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 4FFC014D90 for ; Fri, 5 Nov 1999 12:06:18 -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 VAA23299 for ; Fri, 5 Nov 1999 21:05:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA00920 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 21:05:11 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 4F0F115227 for ; Fri, 5 Nov 1999 12:04:14 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id OAA15995 for ; Fri, 5 Nov 1999 14:59:40 -0500 (EST) Reply-To: Randell Jesup To: arch@freebsd.org Subject: Re: FSM's References: <3822F55C.506F5E48@bachue.usc.unal.edu.co> From: Randell Jesup Date: 05 Nov 1999 16:00:34 +0000 In-Reply-To: "Pedro Fernando Giffuni"'s message of "Fri, 05 Nov 1999 10:18:52 -0500" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 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. -- 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