From owner-freebsd-arch Thu Nov 4 14:56:40 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 60AE915164 for ; Thu, 4 Nov 1999 14:56:37 -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 XAA05485 for ; Thu, 4 Nov 1999 23:54:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA95404 for freebsd-arch@freebsd.org; Thu, 4 Nov 1999 23:54:55 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 6AA6B1570C for ; Thu, 4 Nov 1999 14:50:55 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA23873; Thu, 4 Nov 1999 15:50:22 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd023797; Thu Nov 4 15:50:10 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA19151; Thu, 4 Nov 1999 15:50:09 -0700 (MST) From: Terry Lambert Message-Id: <199911042250.PAA19151@usr07.primenet.com> Subject: Re: Threads goals version III To: peter.jeremy@alcatel.com.au Date: Thu, 4 Nov 1999 22:50:07 +0000 (GMT) Cc: freebsd-arch@freebsd.org In-Reply-To: <99Nov5.085119est.40325@border.alcanet.com.au> from "Peter Jeremy" at Nov 5, 99 08:56:49 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 1999-Nov-05 05:04:17 +1100, Terry Lambert wrote: > >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. I won't bore you with cries of "branch path validation"; I will only point out that any code can be made difficult, or easy, to maintain using literate programming techniques and documentation that covers the actual implementation's design. An FSA is only as hard to follow as its documentation is poor. FSA's also have the advantage of usually being more efficient than multiple threads with explicit IPC and synchronization points, since they don't have to stall execution during them. Nevertheless, it is sometimes as useful to implement using a threaded execution model instead of an FSA, either because you have junior level people doing the implementation, or you expect to have junior level people doing maintenance (in either case, it's _not_ acceptable to do because you "choose not to document" or your "design does not match the code"; either of these will prevent you from doing adequate testing). > >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. I agree. That's why I didn't throw out at least kernel cooperation of some kind; it's just a question of where you place the line in order to get multiple CPU's in user space at the same time. In terms of meeting the goals of having threads in the first place, kernel threads vs. kernel call contexts are an issue to address in terms of implementation strategies. At the same time, you could argue about cache busting, locality of reference, interprocessor contention, and all of the other issues related to enabling either kernel threads or multiple CPU's in user space in the same process in something other than a work-to-do design for a threaded program. As I said: this is an issue of implementation strategy, and I'm happy to keep it seperate from the goals list. 8-). > >Julian has asked me several times to write up my threading model; > >he's seen it on a white board, and I've been able to address all > >of his concerns regarding it there. > > The rest of us would also like to see it. > > Peter I'm working, I'm working. I'm in the middle of a Y2K audit of a network operations center. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message