From owner-freebsd-threads@FreeBSD.ORG Tue Mar 31 15:11:04 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 98372106568B; Tue, 31 Mar 2009 15:11:04 +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 1E5EF8FC15; Tue, 31 Mar 2009 15:11:04 +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 n2VFBAne091217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Mar 2009 11:11:10 -0400 (EDT) (envelope-from rrs@lakerest.net) Message-Id: From: Randall Stewart To: John Baldwin In-Reply-To: <200903311038.43401.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 11:11:02 -0400 References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <200903311038.43401.jhb@freebsd.org> X-Mailer: Apple Mail (2.930.3) Cc: threads@freebsd.org, 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:11:05 -0000 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. 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?? 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 ;-) R On Mar 31, 2009, at 10:38 AM, John Baldwin wrote: > On Tuesday 31 March 2009 2:50:27 am Daniel Eischen wrote: >>> Ok, I have poked around at these... all the mutex attributes >>> defined here >>> do is set the attributes to shared. There does not seem to be any >>> standard >>> naming mechanism. >> >> Naming mechanism for what? Names shouldn't be needed for anything, >> nor do I think it is desired. > > Off topic: names would be very helpful to port witness to pthreads. > The > thoughts I have had for doing this though would be to add a new _np > attribute > to set the name. I actually would like to write a 'libwitness' that > basically overrides the various symbols and provides the name_np > attribute > and implement witness in the shared library on top of whatever > pthreads > library is in use. This would also allow it to be portable to other > OS's. > (Well, it could break pshared mutexes, but using the pointer-style > types, you > could have the libwitness allocate its own "mutex" structure which has > a "real" mutex inside of it along with the name and other per-lock > data it > tracks. It would then forward mutex operations to the real pthreads > library > after performing LOR checks, etc.). > > -- > John Baldwin > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)