Date: Thu, 15 Jul 1999 18:34:28 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: unknown@riverstyx.net (Tani Hosokawa) Cc: tlambert@primenet.com, chat@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <199907151834.LAA28562@usr07.primenet.com> In-Reply-To: <Pine.LNX.4.10.9907141936200.2514-100000@avarice.riverstyx.net> from "Tani Hosokawa" at Jul 14, 99 07:37:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 15 Jul 1999, Terry Lambert wrote: > > > > Applications requiring large numbers of threads. > > Balk. "Rodents of unusual size? I don't believe they exist...". > > BTW, what would you consider to be a large number of threads? 64? 128? > More? How about a threaded webserver? Apache *is* going to be threaded, > you know... There is no "require" about it. Threads are a tool, and equivalent (and lower overhead) tools exist. The idea that threads are necessary at all is a psychological crutch. It has more to do with the inability of programmers to maintain state in a per connection structure, rather than on a stack. It's a programmer problem, in other words, based in procedural (rather than data flow) based ways of thinking. That said, it's useful to be able to have a junior level person who doesn't understand finite state automata be able to produce code for the non-performance-critical parts of your project. At least they can contribute something, and they're cheaper than a senior level person who has a better engineering toolbox at their disposal (e.g. is more educated in the ways of code). Programs that require threads, particularly programs which require kernel threads, are, IMO, broken throw-away code. Topologically (I'm going to get beat on by another topologist for using physics instead of mathematics semantics for this one; please forgive me in advance, wherever you are... 8-)), there is no difference in kernel threads vs. user space call conversion threads vs. async I/O vs. finite state automata implemetnations of an algorithm, with the exception of SMP scalability -- and said scalability can be addressed very easily without resorting to kernel threads in all but the automata case. Given an OS that requires protection domain crossing (e.g. FreeBSD) in order to implement system services, kernel threading actually leads to significantly higher context switch overhead, unless one resorts to heroic (and arcane) avoidance mechanisms (I've discussed this before in this forum, probably ad-to-some-people's-nauseum 8-)). Threads are merely a convenience for linear thinkers, and kernel threads (in the presence of protection domain crossing requirements) are merely a convenience for junior implementors of operating systems. 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-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907151834.LAA28562>