From owner-freebsd-threads@FreeBSD.ORG Tue Mar 31 13:12:03 2009 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E374D10656C4 for ; Tue, 31 Mar 2009 13:12:03 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 820F48FC16 for ; Tue, 31 Mar 2009 13:12:03 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n2VDC2CT028653; Tue, 31 Mar 2009 09:12:02 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 31 Mar 2009 09:12:02 -0400 (EDT) Date: Tue, 31 Mar 2009 09:12:01 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> Message-ID: References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org Subject: Re: A mutex for inter-process ;-) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 13:12:04 -0000 On Tue, 31 Mar 2009, Randall Stewart wrote: > > On Mar 31, 2009, at 2:50 AM, Daniel Eischen wrote: > >> >> They define the API. We should not be making new APIs for something >> that already exists, that applications already know how to use, etc. > > So what you are saying is ... just let the application do it. Provide > nothing but the ability to "mark" a mutex as shared. And let the > app figure it out. Correct. We do not need nor want any more SYS V IPC stuff and have more utilities like ipcrm, ipcs, etc to deal with them. POSIX already defines the API for us and tells us how to use process shared mutexes, et al. > Hmm.. If one company is asking for this ability i.e. easily > do shared mutexs I am sure other folks have wanted it as well. > Now rolling your own is a valid thing to do.. but it seems to > me providing something for general use is not a bad idea either. There already is something for general usage, see POSIX ;-) > The pages you pointed out even show such a mechanism for > semaphores... i.e. there definition of > > semaphore_create(char *shared_name) > semaphore_open(char *shared_name) > semaphore_post(..) > > and kin. > > > Curious place for it though.. under pthread_mutex_destroy() ;-) They are also in the POSIX spec under their own entries. > And of course as pointed out this does not solve the quick death > syndrome (for that matter neither did I yet but I am thinking > about this one ;D)... which is the real hard problem.. and really > does require assistance beyond what an application can generally > do... No, the kernel can do it under the existing umutex API. You should really be asking David Xu this stuff, but the kernel can remove any of its own resources (if it has any allocated) when the shared memory is removed, or it may be possible to have POSIX mutex robustness by having the kernel unlock or deallocate umutex resources upon process termination. The point is, it is possible for the kernel to do this, if it already doesn't, using the existing umutex APIs. > IMO having a general library function available is a good thing. If > you are not interested in seeing it in libthr where I think it would > belong.. thats fine I can build a port or other such... > > I will send Julian the manual page after I get it built through :-D There already is an API for doing what you want, and sorry, but no, I don't think adding a BSD-only API that is different from something POSIX already defines is a good thing ;-) -- DE