From owner-cvs-all@FreeBSD.ORG Fri May 6 18:54:53 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B892016A4D4; Fri, 6 May 2005 18:54:53 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C8B643D6A; Fri, 6 May 2005 18:54:53 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j46IsqkG000730; Sat, 7 May 2005 04:54:52 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j46IsoRL022323; Sat, 7 May 2005 04:54:51 +1000 Date: Sat, 7 May 2005 04:54:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Xu In-Reply-To: <200505060737.j467b2R4041476@repoman.freebsd.org> Message-ID: <20050507043824.P12302@delplex.bde.org> References: <200505060737.j467b2R4041476@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gmon mcount.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 18:54:53 -0000 On Fri, 6 May 2005, David Xu wrote: > davidxu 2005-05-06 07:37:01 UTC > > FreeBSD src repository > > Modified files: > lib/libc/gmon mcount.c > Log: > Fix race by using atomic operation, with this change, both libpthread > and libthr now can run profiling on SMP. > > Revision Changes Path > 1.21 +5 -3 src/lib/libc/gmon/mcount.c Doesn't userland need to wait for mcount() to become unbusy, like the kernel does? Just returning gives broken profiling. mcount() takes a long time, so there is a good chance of a thread being preempted while in mcount(). Then I think profiling is effectively turned off until the thread in mcount() is rescheduled and leaves mcount(). I don't know exactly how to avoid deadlock in userland. The kernel just disables interrupts. Userland would have to stop rescheduling, and do this without calling mcount() or dding much overhead. Note that the kernel must disable interrupts and not just use critical_enter(), since if it used the latter then low level interrupt handling would be complicated and broken by not being able to call mcount(). Bruce