From owner-freebsd-arch Fri Nov 5 15:40: 5 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 3476614E25 for ; Fri, 5 Nov 1999 15:39:36 -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 AAA25973 for ; Sat, 6 Nov 1999 00:38:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA01782 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 00:38:51 +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 C9C8614E25 for ; Fri, 5 Nov 1999 15:38:12 -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 PAA58947; Fri, 5 Nov 1999 15:36:43 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911052336.PAA58947@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 19:16:35 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Nov 1999 15:36:43 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Amancio Hasty 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