From owner-svn-src-all@FreeBSD.ORG Fri Feb 24 01:29:00 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE42C1065676; Fri, 24 Feb 2012 01:29:00 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 904558FC0C; Fri, 24 Feb 2012 01:29:00 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1O1SwAw011182; Fri, 24 Feb 2012 01:28:59 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F46E7D6.4090605@gmail.com> Date: Fri, 24 Feb 2012 09:28:54 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jilles Tjoelker References: <201202220322.q1M3MoFE032330@svn.freebsd.org> <20120222234254.GC95122@stack.nl> <4F458355.8090405@gmail.com> <20120223224310.GA10491@stack.nl> In-Reply-To: <20120223224310.GA10491@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, davidxu@FreeBSD.org Subject: Re: svn commit: r231989 - in head: lib/libthr/thread sys/kern sys/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@FreeBSD.org List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:29:00 -0000 On 2012/2/24 6:43, Jilles Tjoelker wrote: > On Thu, Feb 23, 2012 at 08:07:49AM +0800, David Xu wrote: >> On 2012/2/23 7:42, Jilles Tjoelker wrote: >>> On Wed, Feb 22, 2012 at 03:22:50AM +0000, David Xu wrote: >>>> Author: davidxu >>>> Date: Wed Feb 22 03:22:49 2012 >>>> New Revision: 231989 >>>> URL: http://svn.freebsd.org/changeset/base/231989 >>>> Log: >>>> Use unused fourth argument of umtx_op to pass flags to kernel for operation >>>> UMTX_OP_WAIT. Upper 16bits is enough to hold a clock id, and lower >>>> 16bits is used to pass flags. The change saves a clock_gettime() syscall >>>> from libthr. >>>> Modified: >>>> head/lib/libthr/thread/thr_umtx.c >>>> head/sys/kern/kern_umtx.c >>>> head/sys/sys/umtx.h >>>> >>>> Modified: head/lib/libthr/thread/thr_umtx.c >>>> ============================================================================== >>>> --- head/lib/libthr/thread/thr_umtx.c Wed Feb 22 01:50:13 2012 (r231988) >>>> +++ head/lib/libthr/thread/thr_umtx.c Wed Feb 22 03:22:49 2012 (r231989) >>>> @@ -200,20 +200,10 @@ int >>>> + abstime != NULL ? (void *)(uintptr_t)((clockid<< 16) | UMTX_WAIT_ABSTIME) : 0, >>> Please check that this shift does not lose any information (i.e., >>> clockid>= 0&& clockid<= 0xFFFF) before doing it. >>> Implementing clock_getcpuclockid() will require clockids greater than >>> 65535 because such clockids contain a process id. >> In which document said the clock id includes a process id ? I think the >> clock_getcpuclockid() >> is a simplified version of getrusage(). > clock_getcpuclockid() lets you find a clock ID for the CPU time clock of > a process. Usage could be like this: > > int error; > pid_t pid; > clockid_t clk; > struct timespec ts; > > error = clock_getcpuclockid(pid,&clk); > if (error == 0) > if (clock_gettime(clk,&ts) == 0) > printf("%lu.%09lu\n", (unsigned long)ts.tv_sec, > (unsigned long)ts.tv_usec); > > One way to implement it is to reserve a PID_MAX sized subrange of > clockid_t for this purpose. > > Similarly, pthread_getcpuclockid() lets you find a clock ID for the CPU > time clock of a thread. So the clock ID may be dynamically allocated in theory ? > These seem mostly useful for clock_getres(), clock_gettime() and > possibly timer_create(). Besides, sem_timedwait() doesn't even let you > specify a clock ID. > Yes, sem_timedwait does not specify a clock ID, it is inconsistent with pthread condition variable, it is not surprising, it is not first time that the POSIX has a bug.