From owner-freebsd-stable Wed Dec 20 3:52:28 2000 From owner-freebsd-stable@FreeBSD.ORG Wed Dec 20 03:52:26 2000 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B22E137B400 for ; Wed, 20 Dec 2000 03:52:25 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id GAA01041; Wed, 20 Dec 2000 06:51:59 -0500 (EST) Date: Wed, 20 Dec 2000 06:51:58 -0500 (EST) From: Daniel Eischen To: Andy Newman Cc: stable@FreeBSD.ORG Subject: Re: misc/23679, pthreads and sleep times In-Reply-To: <200012200507.eBK57Gf30708@bebop.silverbrook.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 20 Dec 2000, Andy Newman wrote: > 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. Semaphores are not wrapped by the threads library. You cannot use them reliably in our threaded environment as they will block the entire process. > 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. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message