Date: Sat, 8 Jul 2000 18:48:14 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: hsu@freebsd.org Cc: arch@freebsd.org Subject: Re: yield(2) (was Re: cvs commit: src/libexec/rtld-elf rtld.c rtld.h lockdflt.c) Message-ID: <200007090148.SAA47584@vashon.polstra.com> In-Reply-To: <20000709011338.880E337BA97@hub.freebsd.org> References: <20000709011338.880E337BA97@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20000709011338.880E337BA97@hub.freebsd.org>, Jeffrey Hsu <hsu@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007090148.SAA47584>