Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news2.arglkargh.de!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.programming.threads,comp.unix.programmer Subject: Re: Open issues in the specification for fork()? Date: Mon, 25 Nov 2013 22:16:07 +0000 Lines: 49 Message-ID: <87k3fww2jc.fsf@sable.mobileactivedefense.com> References: <5291d497$0$15884$e4fe514c@news2.news.xs4all.nl> <87hab1kdvw.fsf@sable.mobileactivedefense.com> <52929869$0$15987$e4fe514c@news2.news.xs4all.nl> <20131125011903.172db979@laptop.homenet> <52933db8$0$15988$e4fe514c@news2.news.xs4all.nl> <5293ab24$0$15963$e4fe514c@news2.news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net E6jtBc3Y1XYO41S7Q1AS6gLa8sSf1tIqe0q+Ty8jS+/54M/FY= Cancel-Lock: sha1:ORU6FkszA3dz1QHaWYfjk31fBq8= sha1:oBp1csFqefXtWMyB8efGJQj+9Ds= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.programming.threads:2016 comp.unix.programmer:5042 Casper H.S. Dik writes: > Drazen Kacar writes: [...] >>[1] And, of course, there were people who wrote multi-threaded program, >>but forgot to add one of the thread libraries to the link line. Then the >>program would link fine (because of stubs in libc), but none of the >>thread functions would work. That was a lot of fun for everyone. :-) > > Yes; fortunately, that was fixed when Solaris 10 was released (in 2005) > > But that couldn't be done until we had created a multi-thread library > which behaved more sanely in the presence of just the one thread; > such a library was first shipped with Solaris 8 and was made the default > in Solaris 9. This is described in some detail in a whitepaper named 'Multithreading in the Solaris Operating Environment' published around the time of Solaris 9 which is still worth a read (I actually just reread it). The main change in order to get a 'sanely behaving threading library' was switching from M:N threading to 1:1 threading and thus getting rid of the necessity to use hidden userspace threads in order to try to solve problems inherent in the M:N approach. This includes the remarkable feat of accepting that threads are useful because they enable applications to use multiprocessors AND NOT because they enable university eggheads from 'research assistant' upwards to avoid dealing with state machines in their code (that's a gross oversimplification, mainly because I really don't know how to describe this in a more accurate way). Commercial operating system tend to oscillate between these two models (with the occasional idiot reimplementing cooperative userspace threading for the upteempth time), cf the following statement from HP on 'MxN threading in HP-UX 11i': MxN threads were implemented in response to the perception that enterprise applications creating large numbers of threads perform better with MxN threads than with 1x1. However, The only real way to know how using the MxN model affects the performance of your particular application is to benchmark the two models and compare the results. Or, to put this into other words "While there's a strong perception that such applications ought to exist, there's little real evidence that they actually do".