Date: Tue, 15 Dec 1998 10:44:53 -0500 (EST) From: "Robert S. Sciuk" <rob@ControlQ.com> To: Terry Lambert <tlambert@primenet.com> Cc: James Mansion <james@westongold.com>, mal@algonet.se, alk@pobox.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP Message-ID: <Pine.UW2.3.96.981215101101.5711B-100000@fatlady.controlq.com> In-Reply-To: <199812150732.AAA12768@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.UW2.3.96.981215101101.5711B-100000>