From owner-freebsd-arch Sat Jul 8 18:48:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 5411437BDC8; Sat, 8 Jul 2000 18:48:16 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id SAA25619; Sat, 8 Jul 2000 18:48:15 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id SAA47584; Sat, 8 Jul 2000 18:48:14 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Sat, 8 Jul 2000 18:48:14 -0700 (PDT) Message-Id: <200007090148.SAA47584@vashon.polstra.com> To: hsu@freebsd.org Subject: Re: yield(2) (was Re: cvs commit: src/libexec/rtld-elf rtld.c rtld.h lockdflt.c) In-Reply-To: <20000709011338.880E337BA97@hub.freebsd.org> References: <20000709011338.880E337BA97@hub.freebsd.org> Organization: Polstra & Co., Seattle, WA Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000709011338.880E337BA97@hub.freebsd.org>, Jeffrey Hsu wrote: > What do you think of adding a real yield(2) system call? Well, we already have sched_yield(). Anyway, it wouldn't help the dynamic linker or spinlocks in general. What's needed is not a way for the process to yield the CPU, but a way for the running _thread_ to yield. So the yield implementation has to be tied into the threads package that's being used. And there are N different threads packages. Wine has its own, JDK has its own, Mozilla has its own, and then there's linuxthreads and of course pthreads. > I do the nanosleep too in some locking code I use for a pre-forked > server (like Apache), but I am unhappy with that. I am not too worried about it being "good" in the dynamic linker, because in practice it will spin only very rarely. The only way there is contention now is when a thread tries to do dlopen() or dlclose() while another thread is inside the dynamic linker. That just isn't going to happen very often. > I chosed 100ms as the sleep time because that's one scheduler > quantum (or used to be). It wasn't clear to me that a nanosleep of > anything less than a quantum would guarantee a yield. I don't know what the scheduler quantum is. In the kernel, even a 1 usec. sleep gets rounded up to 1/HZ = 10 msec. However, when a threads package is in use the sleep will be implemented by the threads package. Any sleep there will yield to another thread, I'd think. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message