Date: Thu, 4 Nov 1999 22:50:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version III Message-ID: <199911042250.PAA19151@usr07.primenet.com> In-Reply-To: <99Nov5.085119est.40325@border.alcanet.com.au> from "Peter Jeremy" at Nov 5, 99 08:56:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911042250.PAA19151>