From owner-freebsd-hackers Sun Jan 16 22: 4:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by hub.freebsd.org (Postfix) with ESMTP id 3C35B15124 for ; Sun, 16 Jan 2000 22:04:50 -0800 (PST) (envelope-from archer@lucky.net) Received: from 207-172-201-37.s37.as1.xnb.nj.dialup.rcn.com ([207.172.201.37] helo=unknown.nowhere.org) by smtp01.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 12A5HU-0001y0-00 for hackers@freebsd.org; Mon, 17 Jan 2000 01:04:48 -0500 Received: (from archer@localhost) by unknown.nowhere.org (8.9.3/8.9.3) id AAA47274; Mon, 17 Jan 2000 00:55:04 -0500 (EST) (envelope-from archer) Date: Mon, 17 Jan 2000 00:55:04 -0500 (EST) Message-Id: <200001170555.AAA47274@unknown.nowhere.org> From: Alexander Litvin To: hackers@freebsd.org Subject: Re: Preemptiveness of FreeBSD threads X-Newsgroups: unknown.freebsd.hackers In-Reply-To: <200001170423.XAA10093@pcnet1.pcnet.com> User-Agent: tin/1.4-19991113 ("No Labels") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200001170423.XAA10093@pcnet1.pcnet.com> you wrote: >> 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! >> >> Depending on the phase of the moon (it seems) sometimes my >> program gives (after ^C): >> >> ^C >> Thread 0x00: 0 >> Thread 0x01: 0 >> Thread 0x02: 0 >> Thread 0x03: 0 >> Thread 0x04: 0 >> Thread 0x05: 0 >> Thread 0x06: 0 >> Thread 0x07: 0 >> Thread 0x08: 0 >> Thread 0x09: 0 >> Thread 0x0a: 488133092 > Hmm, I can't get this to occur with your test program. I've tried > it several times and the threads seem to be scheduled properly. > If you figure out how to repeat this without relying on phases of > the moon, I'd be interested in hearing how. That's what makes it most wierd for me -- I am not able to determine conditions when it gives a "wrong" result. I'll keep trying though. I also could probably compile libc_r with debug info and set a breakpoint somewhere in threads scheduler to see what's going on. Or, because it is time-related, it is not a good idea? Then printfs in libc_r -- will they work? Could you suggest a good place to start looking? As I said, it seems to go in periods -- for some time everything is normal, and then for some time -- bullshit :-\ You may try to repeat it after some time. It may also be hardware dependent (?) > Are you running NTP or changing the time? That idea also came to me, but no -- I don't have NTP, and I don't change the time. And as I said, the interrupts seem to keep being delivered to the process. > Dan Eischen > eischen@vigrid.com --- After living in New York, you trust nobody, but you believe everything. Just in case. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message