From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 23 16:27:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E16F9106566C; Fri, 23 Oct 2009 16:27:50 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 908C58FC0C; Fri, 23 Oct 2009 16:27:50 +0000 (UTC) Received: from [172.31.193.10] (cpe-069-134-110-200.nc.res.rr.com [69.134.110.200]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n9NGRnAZ027732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Oct 2009 12:27:49 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n9NGRnAZ027732 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1256315269; bh=knWqu7OFIT2xJ+9wLfLxbkmRoBj+Bh5p4pNm56tudXE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PsgKzK2WJCNttZj5c3iKjZj+lKUJf2RxDOEWknhI2cS1mycRHmHkzWO46Oi7BgCb6 6AG/FrN2asvWuxR9xIgkoW4nDs/oHeMWcSiJj9xrACalgPk69VsQIc79o6JK7jkG+u XV4QZ8VrrRJm9b3Yhgrt/JaYr3QJNB5ZVys8Xksw= Message-ID: <4AE1D97F.6060708@cs.duke.edu> Date: Fri, 23 Oct 2009 12:27:43 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Daniel Eischen References: <4AE0BBAB.3040807@cs.duke.edu> <4AE0C995.5060303@cs.duke.edu> <200910230802.49873.jhb@freebsd.org> <4AE1CE31.1090206@cs.duke.edu> <4AE1D1D2.1090307@cs.duke.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Christian Bell Subject: Re: semaphores between processes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:27:51 -0000 Daniel Eischen wrote: > > We already use umtx. This really is a hack and I wouldn't > advocate it. I'm not sure how you could make it work and > not break existing ability to return appropriate error > codes without slowing down the path in the non-shared > case. You'd have to check to see if the address space > was shared or not, which would require a system call. I'm probably missing something. What does it matter if the address space is shared, as long as the umtx struct is in shared memory? From my quick read, the umtx operations use a lock word in userspace. For uncontested locks, they use atomic ops to flip an id into the lock word. The kernel takes over for contested locks, and does sleeping, wakup, etc. Is this correct? Is there something here that matters if the address space (and not just the lock word) is shared? > All our public pthread_foo() symbols are weak. You > can easily override them in your application code in > the #ifdef freebsd case. What is wrong with providing > your own library that overrides them to do what you > require - this shouldn't change your application code? > For our code, I was thinking of something like: #ifdef FreeBSD #define lock(x) umtx_lock(x, getpid()) #define unlock(x) umtx_unlock(x, getpid()) #else #define lock(x) pthread_mutex_lock(x) #define unlock(x) pthread_mutex_lock(x) #endif I should probably just shut up and try it.. Drew