From owner-freebsd-stable Wed Dec 20 4:43:21 2000 From owner-freebsd-stable@FreeBSD.ORG Wed Dec 20 04:43:19 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 E792A37B400 for ; Wed, 20 Dec 2000 04:43:18 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA07052; Wed, 20 Dec 2000 07:42:53 -0500 (EST) Date: Wed, 20 Dec 2000 07:42:53 -0500 (EST) From: Daniel Eischen Message-Id: <200012201242.HAA07052@pcnet1.pcnet.com> To: andy@silverbrook.com.au, stable@FreeBSD.ORG Subject: Re: misc/23679, pthreads and sleep times Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. > > 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. You're actually seeing the additive times of all the children whom went before. When the process blocks waiting for the semaphore, the clock doesn't get updated (I guess signals from setitimer don't occur when this happens because no work is being done by the kernel nor the application). When the child finally wakes up, the cached clock is used (but it hasn't been updated since the child went to sleep). Here's a bit of a hack to work around the problem: Index: uthread/uthread_nanosleep.c =================================================================== RCS file: /opt/b/CVS/src/lib/libc_r/uthread/uthread_nanosleep.c,v retrieving revision 1.13 diff -u -r1.13 uthread_nanosleep.c --- uthread/uthread_nanosleep.c 2000/01/27 23:07:11 1.13 +++ uthread/uthread_nanosleep.c 2000/12/20 12:38:04 @@ -54,8 +54,12 @@ errno = EINVAL; ret = -1; } else { - /* Get the current time: */ - gettimeofday(&tv, NULL); + /* + * As long as we're going to get the time of day, we + * might as well store it in the global time of day: + */ + gettimeofday((struct timeval *) &_sched_tod, NULL); + GET_CURRENT_TOD(tv); TIMEVAL_TO_TIMESPEC(&tv, ¤t_time); /* Calculate the time for the current thread to wake up: */ @@ -73,8 +77,12 @@ /* Reschedule the current thread to sleep: */ _thread_kern_sched_state(PS_SLEEP_WAIT, __FILE__, __LINE__); - /* Get the current time: */ - gettimeofday(&tv, NULL); + /* + * As long as we're going to get the time of day, we + * might as well store it in the global time of day: + */ + gettimeofday((struct timeval *) &_sched_tod, NULL); + GET_CURRENT_TOD(tv); TIMEVAL_TO_TIMESPEC(&tv, ¤t_time1); /* Calculate the remaining time to sleep: */ -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message