From owner-svn-src-head@FreeBSD.ORG Sun May 15 08:34:30 2011 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF796106566B; Sun, 15 May 2011 08:34:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 640AA8FC0C; Sun, 15 May 2011 08:34:28 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA10404; Sun, 15 May 2011 11:34:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QLWmF-0004zO-Ht; Sun, 15 May 2011 11:34:15 +0300 Message-ID: <4DCF9007.7010606@FreeBSD.org> Date: Sun, 15 May 2011 11:34:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bruce Evans References: <201105091734.p49HY0P3006180@svn.freebsd.org> <201105121239.31340.jkim@FreeBSD.org> <4DCD2875.9040808@FreeBSD.org> <201105131257.34009.jkim@FreeBSD.org> <20110514041838.S2545@besplex.bde.org> In-Reply-To: <20110514041838.S2545@besplex.bde.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Jung-uk Kim Subject: Re: svn commit: r221703 - in head/sys: amd64/include i386/include x86/isa x86/x86 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 08:34:30 -0000 on 13/05/2011 22:14 Bruce Evans said the following: > It might happen for clock_gettime() > in separate threads where the threads somehow know and depend on the > order of the calls. My simplistic world view is that those threads then should be the place to do all the fence dances, not the generic tsc read function. But, hey, I am speaking beyond my knowledge of their code and situation. -- Andriy Gapon