From owner-freebsd-chat Fri Jul 16 15:57:31 1999 Delivered-To: freebsd-chat@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id BD3D814DE4 for ; Fri, 16 Jul 1999 15:57:27 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA17019; Fri, 16 Jul 1999 16:13:50 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd016930; Fri Jul 16 16:13:37 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA16303; Fri, 16 Jul 1999 15:57:11 -0700 (MST) From: Terry Lambert Message-Id: <199907162257.PAA16303@usr05.primenet.com> Subject: Re: Known MMAP() race conditions ... ? To: davids@webmaster.com (David Schwartz) Date: Fri, 16 Jul 1999 22:57:11 +0000 (GMT) Cc: tlambert@primenet.com, unknown@riverstyx.net, chat@FreeBSD.ORG In-Reply-To: <000001becf24$b6b12eb0$021d85d1@youwant.to> from "David Schwartz" at Jul 15, 99 05:47:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > So, what we get back to is, what's one thing that's wrong with FreeBSD? > > > Threads. > > > > That's actually "what's wrong with applications?". The closest you > > can get to blaiming FreeBSD for this is "why can't FreeBSD run > > these applications that rely on threads in an SMP scalable way?". I > > could easily ask a similar question: "why can't FreeBSD run Microsoft > > Office 2000?". > > No, there is a legitimate question here that you are evading. Why does > FreeBSD block a whole process if one thread blocks? There is no requirement > that it do so. The standards suggest otherwise. FreeBSD's support of POSIX > threads is deficient. FreeBSD's user space threads implementation uses call conversion to wrap system calls. As a result, "blocking" system calls do not block other threads. In point of fact, a "blocking" call made by a thread will result in a user space threads scheduler entry, which will result in that thread being suspended until the blocking call can be completed without blocking. This is the definition of a "user space threads call conversion scheduler", which is a permissable implementation, according to POSIX 1003.1c. If you are talking about non-system call interfaces that sit in spin loops (e.g. library calls), then you are talking about something else being the source of your problem (i.e. it's not FreeBSD's fault that the code does not work, it's the code's fault). Such problem code should be corrected to use a pthread_mutex_t, and not a spin loop, per the recommendation of POSIX 1003.1c, which is the standard which defines the pthreads interface. In other words: Q: "Why does FreeBSD block a whole process if one thread blocks?" A: "Because the code that is blocking is buggy." My recommendations would be: 1) Make sure you are linking against libc_r and not libc 2) If the problem is in a library, fix the library. Most GNU derived libraries (GDBM, etc.) have the perverse assumption about the implemetnation architecture, despite the POSIX 1003.1c requirements for writing working programs. 3) If your code, itself, is using spin locks, fix it, becuase you should be using pthreads synchrinization primitives if you are calling pthreads interfaces (e.g. pthread_create). 4) If you can identify a bonifide test case in FreeBSD where a FreeBSD supplied library or system call causes a block rather than a call conversion, please provide a test case, and it will be fixed. I have had no problems running LDAP, ACAP, and other well-written pthreads using code on FreeBSD, without seeing the problems you are claiming to see. Let me know when/if you can provide any test cases, and I will be happy to help diagnose the actual source of the problem. 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