From owner-freebsd-threads@FreeBSD.ORG Tue Mar 31 15:34:37 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 792571065721 for ; Tue, 31 Mar 2009 15:34:37 +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 459918FC19 for ; Tue, 31 Mar 2009 15:34:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id C6A4546B1A; Tue, 31 Mar 2009 11:34:36 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2VFYUYW032521; Tue, 31 Mar 2009 11:34:30 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Randall Stewart Date: Tue, 31 Mar 2009 11:27:06 -0400 User-Agent: KMail/1.9.7 References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <200903311038.43401.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200903311127.06447.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 31 Mar 2009 11:34:31 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9186/Tue Mar 31 05:51:33 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-threads@freebsd.org Subject: Re: WITNESS for pthreads 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: Tue, 31 Mar 2009 15:34:39 -0000 On Tuesday 31 March 2009 11:11:02 am Randall Stewart wrote: > This was one of the places I was heading (as I wrote privately to > Daniel ;-D) > > I suppose I can share it all i.e. the pthread mutex stuff > will of course work with shared mutexe's but it won't: > > a) Build an easy to use semantic for the app to agree on sharing > memory.. i.e. you > have left undefined how the process figure out what they are > sharing. There is > some value in setting up a easy semantic for app dev's to use. You can use shm_open() to share memory regions by name and then create mutexes and condvars in that. > interface> > > b) What happens when a process exits or hits a core dump while holding > one > of these mutex's? Is this what you are thinking the PROCESS_SHARED > would > do?? There is a "robust" mutex extension David Xu mentioned. Presumably though what would happen is that when one thread went to block on a mutex, the kernel (in the umtx code) would see if the current owning thread had exited, and if so, do something "appropriate" (break the lock, etc.) at that time. I think a (pid, tid, process starttime) tuple would work ok for detecting this. > the > PROCESS_SHARED could be made to help here> > > c) If you build something to do so you have some nice way of naming > mutex's you can do something similar to our WITNESS option in the > kernel... this is something the few times I have played in user > space recently that I have missed... having LOR warnings and such > can be a useful tool. You can't have this without IMO. > > > I was am interested in a/b but one of my long term intents is to do > ;-) All my WITNESS thoughts are completely separate from PROCESS_SHARED mutexes and I think actually break PROCESS_SHARED mutexes. (Though perhaps they can still be made to work but using something far more invasive where WITNESS defines its own pthread_mutex structure that the app has to be compiled against.) -- John Baldwin