Date: Sun, 16 Jan 2000 21:44:16 -0800 From: Jason Evans <jasone@canonware.com> To: Wes Peters <wes@softweyr.com> Cc: hackers@FreeBSD.ORG Subject: Re: Preemptiveness of FreeBSD threads Message-ID: <20000116214416.S302@sturm.canonware.com> In-Reply-To: <3882A640.2A63B02A@softweyr.com>; from wes@softweyr.com on Sun, Jan 16, 2000 at 10:18:56PM -0700 References: <Pine.BSF.4.05.10001162336110.179-100000@bsd1.nyct.net> <3882A640.2A63B02A@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000116214416.S302>