From owner-freebsd-smp Tue Dec 15 07:40:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA09939 for freebsd-smp-outgoing; Tue, 15 Dec 1998 07:40:38 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from alpha.netaccess.on.ca (netaccess.on.ca [199.243.225.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA09930; Tue, 15 Dec 1998 07:40:34 -0800 (PST) (envelope-from rob@ControlQ.com) Received: from fatlady.controlq.com (dial057.netaccess.on.ca [199.243.225.185]) by alpha.netaccess.on.ca (8.8.5/8.7.3) with SMTP id KAA13453; Tue, 15 Dec 1998 10:39:20 -0500 (EST) Date: Tue, 15 Dec 1998 10:44:53 -0500 (EST) From: "Robert S. Sciuk" To: Terry Lambert cc: James Mansion , mal@algonet.se, alk@pobox.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP In-Reply-To: <199812150732.AAA12768@usr06.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 15 Dec 1998, Terry Lambert wrote: much relevant experience and keen observation snipped ... (hmmm a `yes but'..) > > Just because you have a lot of work to do doesn't mean using threads > will make it faster. Or SMP, for that matter. > Terry, I agree with your above statement, and I generally find your posts to be well though and useful. I must take the side of the pthreads people on this thread, however. Your experience with NWU is valid -- and probably close to an optimal solution for high performance daemons in the Unix context. The schism here, IMHO, seems to be between those who have embraced the pthreads approach, vs those who might be capable of implementing kernel scheduling for the pthreads API's. Processor affinity and cache issues are not immediately apparent to those who have not had to squeeze the last bit of performance out of system level software (as you have). I argue that most applications can be successful, however, without completely linear scalability. The lack of a consistent lightweight lock and synchronization mechanism (eg: user space memory semaphores rather than the heavy kernel SYSV sems) across platforms makes shared (mmap) memory a much harder implementation than pthreads for the average programmer. The select() mechanism and asynch io is also a viable, albeit conceptually more difficult to implement for the average programmer. Pthreads offer the potential for an application level developer type to harness multiple CPU architectures for their own applications in a pseudo portable fashion. CPU affinity and scheduling notwithstanding, it is conceptually simpler to implement a threaded application `correctly'. Reading between the lines, you seem to be saying that writing good (scalable?) applications is hard, and should be hard. Pthreads is a way of allowing at least some of the power of SMP boxes to be accessed by a larger number of developers than some of the historical approaches we have used. (By the way, I was an OEM for NWU on the HP platforms for some years in my former life where the ISO model of the network model was, if not coined, at least widely espoused. I think the top three layers are somewhat universal 8-). Philosopy Religion Politics Application Presentation System Transport Network Datalink Physical I hope that this rather rambling diatribe will be taken in the spirit that it is offered. Cheers, Rob. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert S. Sciuk 1032 Howard Rd. PO Box 6A Ph:905 632-2466 Control-Q Research Burlington, Ont. Canada Fx:905 632-7417 rob@ControlQ.com L7R 3X5 http://www.ControlQ.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message