Date: Tue, 25 Aug 1998 03:53:18 -0400 From: "Gary Palmer" <gpalmer@FreeBSD.ORG> To: Chuck Robey <chuckr@glue.umd.edu> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Threads across processors Message-ID: <3686.904031598@gjp.erols.com> In-Reply-To: Your message of "Tue, 25 Aug 1998 00:52:52 EDT." <Pine.BSF.4.00.9808250047200.361-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Chuck Robey wrote in message ID <Pine.BSF.4.00.9808250047200.361-100000@picnic.mat.net>: > Yeah, I agree. I've written some threaded code for classes, and it > worked just fine. You get some definite speed improvements for threaded > code (if it's kernel threads and you have multiple processors) but > honestly, I don't think that there's all that much code out there that > makes use of it (it's a bear to write). >From an ISP standpoint: Cyclone, Typhoon and Breeze (from Hywind Software) are all threaded. Why? Because it allows them to be a really fast system. Intermail (and probably post.office) from software.com are threaded too (Intermail even uses threaded tcl). This allows them to do some really neat tricks with respect to mail processing. Various LDAP and Radius implimentations are threaded too. Why? Because it allows the system to block on something (e.g. looking up a username in a remote realm) but still process local requests while waiting for an answer. Threading may be work, but it makes a lot of time-critical stuff (where blocking would be bad) easier. Theres a bunch of other stuff out there that *should* be threaded, but unfortunately our threads support, while complete, seems to be a bit slow at times, so I don't think there are as many threaded apps as for (say) Solaris, which is basically totally threaded (even tho the rest of solaris sucks) > For the most part, for the batch type stuff, I'm still willing to do the > multiple process route, client-server stuff. You do see benefit from that, > the complexity is lower, and you don't tear your hair out dealing with > locking. The message passing overhead between processes is much higher than message passing between threads in the same process. I believe Cyclones time-to-transit for an article is on the order of milliseconds. By the time you dump the data on a pipe, incur the context switch, etc, you've lost the advantage. Heck, SMI wrote `doors' for the very reason that IPC *blows* in all cases, and that to pull off the speedups with NSCD that they wanted, they had to get the IPC overhead reduced a lot. I think I even have slides somewhere comparing pipes, SYSV SHM, etc times for message passing in terms of transit time. So, I think you are missing a lot of real-time applications too. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3686.904031598>