Date: Tue, 25 Aug 1998 10:11:54 +0100 From: Paul Richards <paul@originative.co.uk> To: "'Gary Palmer'" <gpalmer@FreeBSD.ORG>, Chuck Robey <chuckr@Glue.umd.edu> Cc: freebsd-current@FreeBSD.ORG Subject: RE: Threads across processors Message-ID: <E40CBF0361C7D111914000C0F0303D1086D2@OCTOPUS>
next in thread | raw e-mail | index | archive | help
Hotmail are apparently dropping FreeBSD in favour of Solaris because of thread support as well :-( Paul Richards Ph.D. Originative Solutions Ltd > -----Original Message----- > From: Gary Palmer [mailto:gpalmer@FreeBSD.ORG] > Sent: Tuesday, August 25, 1998 8:53 AM > To: Chuck Robey > Cc: freebsd-current@FreeBSD.ORG > Subject: Re: Threads across processors > > > 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 > 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?E40CBF0361C7D111914000C0F0303D1086D2>