From owner-freebsd-threads@FreeBSD.ORG Tue Mar 31 19:56:10 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 643F7106564A; Tue, 31 Mar 2009 19:56:10 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id DD9F38FC16; Tue, 31 Mar 2009 19:56:09 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n2VJuFvl002628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Mar 2009 15:56:16 -0400 (EDT) (envelope-from rrs@lakerest.net) Message-Id: <989B6D28-243F-4A13-8C9D-F9C1CD5C2D77@lakerest.net> From: Randall Stewart To: John Baldwin In-Reply-To: <200903311127.06447.jhb@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 15:56:07 -0400 References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <200903311038.43401.jhb@freebsd.org> <200903311127.06447.jhb@freebsd.org> X-Mailer: Apple Mail (2.930.3) 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 19:56:12 -0000 On Mar 31, 2009, at 11:27 AM, John Baldwin wrote: > 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. Thats what my little ipc_mutex...() functions do ;-) > > >> > 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. If that is implemented.. I need to go look into this.. what I found when I was doing some digging is that umtx was used.. and I saw no way to make them "robust".. it may be something that needs adding.. > > >> > 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.) Which could also be put in shared memory so that you could learn the lock ordering across multiple processes ;-) R > > > -- > John Baldwin > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)