From owner-freebsd-stable Tue Dec 19 21: 7:26 2000 From owner-freebsd-stable@FreeBSD.ORG Tue Dec 19 21:07:24 2000 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from entoo.connect.com.au (entoo.connect.com.au [192.189.54.8]) by hub.freebsd.org (Postfix) with ESMTP id AC23837B400 for ; Tue, 19 Dec 2000 21:07:22 -0800 (PST) Received: from bebop.silverbrook.com.au (CPE-144-132-149-109.nsw.bigpond.net.au [144.132.149.109]) by entoo.connect.com.au (Postfix) with ESMTP id 77773DD919 for ; Wed, 20 Dec 2000 16:05:59 +1100 (EST) Received: (from andy@localhost) by bebop.silverbrook.com.au (8.11.1/8.11.1) id eBK57Gf30708 for stable@FreeBSD.org; Wed, 20 Dec 2000 16:07:16 +1100 (EST) (envelope-from andy) Message-Id: <200012200507.eBK57Gf30708@bebop.silverbrook.com.au> Date: Wed, 20 Dec 2000 16:07:15 +1100 (EST) From: Andy Newman Reply-To: andy@silverbrook.com.au Subject: misc/23679, pthreads and sleep times To: stable@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While getting Doug Schmidt's ACE & TAO up and running on RELENG_4 I ran into a curious problem with sleep time calculations and libc_r. One of ACE's test programs - Process_Mutex_Test - uses SysV semaphores for inter-process synchronization (funny that). It forks a number of children which grab the semaphore, do some work, release the semaphore and exit. Work is simulated by sleeping for two seconds so the overall run-time should be in the order the number of children. I noticed that this test didn't seem to finish. A little investigation showed each child was actually sleeping for 2**N (plus a constant :) seconds, N being the ordinal number of the child in the fork loop. I've recreated the test case (attached to report) and tracing it's system calls shows the timeouts being passed to poll() from the thread scheduler are wrong. Yes I aware the timeouts are not guaranteed however I doubt the behaviour I'm seeing is actually desired. Any thoughts? -- Andy Newman, Principal Software Engineer, Silverbrook Research To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message