From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 23 15:39:38 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 C161D106566C; Fri, 23 Oct 2009 15:39:38 +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 748508FC15; Fri, 23 Oct 2009 15:39:38 +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 n9NFdbYW024946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Oct 2009 11:39:37 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n9NFdbYW024946 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1256312377; bh=ubFuS5RpnbEDksjH9chxijWie5C0nifsY5MSBoKx+m0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JdCDZrZ+LRt9Y6iwMHIkQ66mM77lpMp33eyn/w/2mZgXjrdae/pBP/EKaIR2SiG88 3SjMSEl1ZG7v0RbBfz4L78GvkTePf5E+72CEhX4hUqb90sC1c+v7roTCQYh2ABkohs Ckw+DTDWUxEDzybKVPU73wDejYKqQs+ycqGPKSTk= Message-ID: <4AE1CE31.1090206@cs.duke.edu> Date: Fri, 23 Oct 2009 11:39:29 -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> 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 15:39:38 -0000 Daniel Eischen wrote: > On Fri, 23 Oct 2009, John Baldwin wrote: > >> On Thursday 22 October 2009 5:17:07 pm Daniel Eischen wrote: >>> On Thu, 22 Oct 2009, Andrew Gallatin wrote: >>> >>>> Daniel Eischen wrote: >>>>> On Thu, 22 Oct 2009, Andrew Gallatin wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> We're designing some software which has to lock access to >>>>>> shared memory pages between several processes, and has to >>>>>> run on Linux, Solaris, and FreeBSD. We were planning to >>>>>> have the lock be a pthread_mutex_t residing in the >>>>>> shared memory page. This works well on Linux and Solaris, >>>>>> but FreeBSD (at least 7-stable) does not support >>>>>> PTHREAD_PROCESS_SHARED mutexes. >>>>>> >>>>>> We then moved on to posix semaphores. Using sem_wait/sem_post >>>>>> with the sem_t residing in a shared page seems to work on >>>>>> all 3 platforms. However, the FreeBSD (7-stable) man page >>>>>> for sem_init(3) has this scary text regarding the pshared >>>>>> value: >>>>>> >>>>>> The sem_init() function initializes the unnamed semaphore >>>>>> pointed to >>>>>> by >>>>>> sem to have the value value. A non-zero value for pshared >>>>>> specifies >> a >>>>>> shared semaphore that can be used by multiple processes, which >>>>>> this >>>>>> implementation is not capable of. >>>>>> >>>>>> Is this text obsolete? Or is my test just "getting lucky"? >>>>> >>>>> I think you're getting lucky. >>>> >>>> Yes, after playing with the code some, I now see that. :( >>>> >>>>>> Is there recommended way to do this? >>>>> >>>>> I believe the only way to do this is with SYSV semaphores >>>>> (semop, semget, semctl). Unfortunately, these are not as >>>>> easy to use, IMHO. >>>> >>>> Yes, they are pretty ugly, and we were hoping to avoid them. >>>> Are there any plans to support either PTHREAD_PROCESS_SHARED >>>> mutexes, or pshared posix semaphores in FreeBSD? >>> >>> It's planned, just not (yet) being actively worked on. >>> It's a API change mostly, and then adding in all the >>> compat hooks so we don't break ABI. >> >> There are also an alternate set of patches on threads@ to allow just >> shared >> semaphores I think w/o the changes to the pthread types. I can't recall >> exactly what they did, but I think rrs@ was playing with using umtx >> directly >> to implement some sort of process-shared primitive. > > That's really not the way to go. The structs really need > to become public. > It would be great if they were, but that discussion was 6 months ago, and nothing seems to have happened. Plus we need to support at least 7.X and probably 6, so any changes here might not even help us. What is wrong with just using umtx directly? It seems to do exactly what we need. Thanks, Drew