From owner-freebsd-hackers Sun Jan 16 21:45:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 57B1714C59 for ; Sun, 16 Jan 2000 21:45:12 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 26994 invoked by uid 1001); 17 Jan 2000 05:44:16 -0000 Date: Sun, 16 Jan 2000 21:44:16 -0800 From: Jason Evans To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: Preemptiveness of FreeBSD threads Message-ID: <20000116214416.S302@sturm.canonware.com> References: <3882A640.2A63B02A@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3882A640.2A63B02A@softweyr.com>; from wes@softweyr.com on Sun, Jan 16, 2000 at 10:18:56PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 16, 2000 at 10:18:56PM -0700, Wes Peters wrote: > Michael Bacarella wrote: > > > > > Program, when killed with SIGINT, prints all counters and exits. > > > > > > Now, as I understand, userspace threads in FreeBSD are preemptive. > > > So, though my 11 threads are all computational and do not do > > > any syscalls, sleeps, sched_yield, whatever -- newertheless, > > > the program should not be stuck in one thread. And it seems to > > > be sometimes true. But only sometimes! > > > > Hmmm, my prior response was pretty much bullshit. It doesn't work > > for me with 'volatile' at all. > > > > [...] > > > > Putting a sched_yield(); in the loop body makes sure that they get their > > fair share, so, other than guessing FreeBSD is at fault, I'm out of ideas. :) > > Yup, that does it, but it makes the program several orders of magnitude slower, > too. Be careful about how much you use sched_yield, you're pushing the system > into behavior that is outside its normal operating design. FreeBSD wasn't > designed to re-run the scheduler after 2 or 3 instructions. In the case of libc_r, a call to sched_yield doesn't result in the system call sched_yield. Rather, it causes the userland threads scheduler to be run. There is still plenty of overhead, but running the kernel scheduler isn't necessarily part of that overhead. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message