From owner-freebsd-threads@FreeBSD.ORG Thu Dec 24 13:00:28 2009 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BB42106568D; Thu, 24 Dec 2009 13:00:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1E17F8FC13; Thu, 24 Dec 2009 13:00:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C5A0B46B06; Thu, 24 Dec 2009 08:00:27 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 792978A01D; Thu, 24 Dec 2009 08:00:26 -0500 (EST) From: John Baldwin To: David Xu Date: Thu, 24 Dec 2009 07:55:11 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <4B317741.8080004@freebsd.org> <200912230936.35998.jhb@freebsd.org> <4B32C1DC.9080308@freebsd.org> In-Reply-To: <4B32C1DC.9080308@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912240755.11841.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 24 Dec 2009 08:00:27 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-threads@freebsd.org Subject: Re: first patch for process-shared semaphore 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: Thu, 24 Dec 2009 13:00:28 -0000 On Wednesday 23 December 2009 8:20:28 pm David Xu wrote: > John Baldwin wrote: > > On Tuesday 22 December 2009 8:49:53 pm David Xu wrote: > >> This is my first attempt to make process-shared mutex work, this means > >> you can mmap(MAP_SHARED) a memory area, and put semaphore there, > >> or you can sem_open a named semaphore, and just use it between > >> processes, the named semaphore uses file system and mmap(), directory > >> /tmp/.semaphore is used as IPC directory, any named semaphore > >> locates in the directory. old semaphore implementation still exists > >> to make it binary compatible, it uses symbol version. > >> > >> http://people.freebsd.org/~davidxu/patch/shared_semaphore_1.patch > > > > I would suggest that you leave named semaphores as they currently exist and > > follow this approach instead: > > > > 1) Named semaphores use ksem_*() still. > > 2) sem_init/sem_destroy operate on UTMX-backed semaphores identical to the > > ones used in the current libthr code. The semid_t structure now becomes the > > full structure that libthr currently allocates with a flag to indicate if it > > is a "system" semaphore or otherwise. The pshared flag passed to sem_init() > > can be used to set the sharing properties of the UMTX. > > 3) All of sem_init/sem_destroy is just in libc. Just move the libthr > > implementation bits into libc. > > > > ksem base shared semaphore is slow because whenever you call > sem_wait(), it always enters kernel even if count is non-zero, > sem_post() also always enters kernel even if there is no waiter. > but the new implementation is as simple as just an atomic operation > in these cases, I know another competitor OS is doing things in > this way. Yes, Solaris uses files in /tmp and Darwin uses special file descriptors similar to what we do. However, you will have to restrict the namespace if you go the /tmp route to be safe I think similar to what Solaris does (no path separators, just simple names like 'foo'). You might also want to use the same naming convention as Solaris if you go the /tmp route (I think they use a path other than .semaphore under /tmp IIRC). Not sure if we want to do anything special to ensure that those particular set of files in /tmp always get purged on reboot to avoid weird bugs with semaphores unexpectedly persisting across reboots. -- John Baldwin