From owner-freebsd-threads@FreeBSD.ORG Mon Apr 10 11:03:06 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A666A16A401 for ; Mon, 10 Apr 2006 11:03:06 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6754043D49 for ; Mon, 10 Apr 2006 11:03:06 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k3AB361k092773 for ; Mon, 10 Apr 2006 11:03:06 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k3AB35TZ092767 for freebsd-threads@freebsd.org; Mon, 10 Apr 2006 11:03:05 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Apr 2006 11:03:05 GMT Message-Id: <200604101103.k3AB35TZ092767@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2006 11:03:06 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [threads] [patch] Threaded applications e o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag o [2005/01/26] threads/76694threads fork cause hang in dup()/close() function p [2005/03/10] threads/78660threads Java hangs unkillably in STOP state after o [2005/04/08] threads/79683threads svctcp_create() fails if multiple threads o [2005/04/28] threads/80435threads panic on high loads o [2005/05/19] threads/81258threads Thread specific data is sometimes assigne o [2005/07/22] threads/83914threads [libc] popen() doesn't work in static thr o [2005/08/02] threads/84483threads problems with devel/nspr and -lc_r on 4.x o [2005/08/20] threads/85160threads [libthr] [patch] libobjc + libpthread/lib p [2005/11/19] threads/89262threads [kernel] [patch] multi-threaded process h o [2005/12/12] threads/90278threads libthr, ULE and -current produces >100% W o [2006/01/03] kern/91266 threads [threads] Trying sleep, but thread marked o [2006/03/07] threads/94176threads KSE: sigwait doesn't recieve SIGWINCH sen o [2006/03/15] threads/94467threads send(), sendto() and sendmsg() are not co 32 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/04/13] threads/79887threads [patch] freopen() isn't thread-safe o [2005/05/13] threads/80992threads abort() sometimes not caught by gdb depen o [2005/05/26] threads/81534threads [libc_r] [patch] libc_r close() will fail 11 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Apr 11 17:36:32 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF5C016A405 for ; Tue, 11 Apr 2006 17:36:32 +0000 (UTC) (envelope-from martin0406@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [212.44.26.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 571F943D45 for ; Tue, 11 Apr 2006 17:36:32 +0000 (GMT) (envelope-from martin0406@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (localhost.cam.lispworks.com [127.0.0.1]) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9) with ESMTP id k3BHaLDW099973; Tue, 11 Apr 2006 18:36:21 +0100 (BST) (envelope-from martin0406@lwfs1-cam.cam.lispworks.com) Received: (from root@localhost) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9/Submit) id k3BHaK4k099972; Tue, 11 Apr 2006 18:36:20 +0100 (BST) (envelope-from martin0406) Date: Tue, 11 Apr 2006 18:36:20 +0100 (BST) From: martin0406@lispworks.com Message-Id: <200604111736.k3BHaK4k099972@lwfs1-cam.cam.lispworks.com> To: freebsd-threads@freebsd.org Subject: pthread timing granularity with compat5x on FreeBSD 6.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2006 17:36:32 -0000 Hi there, Is there some known issue with the granularity of scheduling when running FreeBSD 5.x executables on FreeBSD 6.0 with compat5x? The sample code below, describes the problem. Any clues could be appreciated. My config is as follows: kern.osrelease: 6.0-RELEASE kern.osrevision: 199506 kern.version: FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC hw.model: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ ------------------------------------------------------------------------------ /* This code demonstrate a problem with sleeping on FreeBSD 6.0 when running code that was compiled on FreeBSD 5.x, when another pthread is busy. The function LoopingSignaler tries to sleep for a fixed period of time. When this is compiled on FreeBSD 5 and run on FreeBSD 5, it sleeps for approximately the right time. When it is compiled on FreeBSD 5 and run on FreeBSD 6 it seems to sleep in "granules" of ~157 ms when competing for CPU time with another thread. To test: compile on FreeBSD 5 by gcc -pthread we.c run on FreeBSD 6 a.out [millseconds] The test starts a pthread that sleeps in a loop reporting the length of time it slept. The main thread then calls usleep for a while, and finally starts to use the cpu heavily (empty while loop). As long it is usleeping, the sleep time of the other pthread is correct. Once it starts using cpu, the sleep time increase to the granule boundary. The sleeping thread prints the time it slept in miliiseconds, first in cpu time (by times(2), and then elapsed time by gettimeofday(2)). By default it tries to sleep for 50 milliseocnds. */ #include #include #include #include #include #include #include #include #include #include void *LoopingSignaler(void *arg) { long tick_per_second = sysconf(_SC_CLK_TCK); clock_t start_sleep; struct timeval tm; int count = 100; int millis = (int) arg; while(count--) { int use_select = count & 1; struct timeval in; struct timespec ain, aout; struct tms tmbuf; in.tv_sec = 0; in.tv_usec = millis * 1000; ain.tv_sec = 0; ain.tv_nsec = millis * 1000000; /* Record the start times */ times(&tmbuf); gettimeofday(&tm, NULL); start_sleep = tmbuf.tms_utime; /* Sleep in two different ways. */ if (use_select) select(1, NULL , NULL , NULL, &in); else nanosleep(&ain, &aout); /* Display time spent sleeping */ { clock_t diff; long millis_sleep, millis_real; struct timeval etm; times(&tmbuf); gettimeofday(&etm, NULL); diff = tmbuf.tms_utime - start_sleep; millis_sleep = (diff * 1000) / tick_per_second; { int secdiff = etm.tv_sec - tm.tv_sec; int micsdiff = etm.tv_usec - tm.tv_usec; millis_real = (micsdiff + secdiff * 1000000) / 1000; } printf("%s slept for %d / %d\n", use_select ? " select": "nanosleep", millis_sleep, millis_real); } } exit(0); } int main(int argc, char **argv) { int millis = 50; pthread_t pt; pthread_attr_t attr; int res; if (argc > 1) millis = atoi(argv[1]); pthread_attr_init(&attr); res = pthread_create(&pt, &attr, &LoopingSignaler, (void *)millis); /* initial test with the main thread idle */ usleep(millis * 1000 * 20); printf("\nfinished usleep\n\n"); /* second test with the main thread busy */ while(1) {}; return 0; } ------------------------------------------------------------------------------ __Martin