From owner-freebsd-current Sun Aug 16 08:43:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA23168 for freebsd-current-outgoing; Sun, 16 Aug 1998 08:43:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA23146 for ; Sun, 16 Aug 1998 08:43:40 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id LAA08806; Sun, 16 Aug 1998 11:43:34 -0400 (EDT) Date: Sun, 16 Aug 1998 11:43:34 -0400 (EDT) From: Daniel Eischen Message-Id: <199808161543.LAA08806@pcnet1.pcnet.com> To: eischen@vigrid.com, jb@cimlogic.com.au, lists@tar.com, shmit@kublai.com Subject: Re: Bug in pthread scheduler? (Was pthreads woes revisited) Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Seaman, Jr wrote: > > On Fri, 7 Aug 1998 10:06:43 -0400, Brian Cully wrote: > > >On Thu, Aug 06, 1998 at 05:13:02PM -0400, Daniel Eischen wrote: > >> You're not adding the pthread_yield() call that I added after > >> the pthread_cond_signal(). Your program is bogus because there > >> is no guarantee that the main thread will release the CPU in > >> order for the other task to run. You need to perform some > >> sort of blocking operation after the pthread_cond_signal. I > >> chose to use pthread_yield, although sleep would work just as > >> well. > > > >Do'h! I missed that. That did make the sample program work, so > >it looks like the error was mine all along, sorry for troubling > >everybody. > > Actually, its not at all clear to me that you need the pthread_yield() > call. In looking at the pthread scheduler, it appears that the > scheduler should preempt (with in the context of the process) the > main thread periodically. It also appears that there might be a bug > in the scheduler code. Try the following diff and see what you get. The scheduler should preempt the threads periodically, but the way the sample was coded, the main thread was sleeping while holding the mutex that the other thread needed to run. When the main thread sleeps, its "time running" should get reset. The main thread didn't do much while awake, so there is no guarantee that it will have its time quantum exceeded. Note that the same program *never* allowed the other thread to run under Solaris. I still maintain the program is bogus because you can't guarantee that the other thread will run when you want it to run (every time it is signaled). Perhaps you've found a bug, but you haven't convinced me that the sample program should work as it was intended to ;-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message