From owner-freebsd-threads@FreeBSD.ORG Wed Apr 1 01:34:43 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 24CDA1065673; Wed, 1 Apr 2009 01:34:43 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E84AE8FC0A; Wed, 1 Apr 2009 01:34:42 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n311YcqO016994; Wed, 1 Apr 2009 01:34:40 GMT (envelope-from davidxu@freebsd.org) Message-ID: <49D2C4B0.2020805@freebsd.org> Date: Wed, 01 Apr 2009 09:34:40 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Randall Stewart References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <200903311038.43401.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 01 Apr 2009 01:34:43 -0000 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. > > 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?? > > PROCESS_SHARED could be made to help here> > Yes, kernel has to involve in this area, maybe all locking and unlocking for PROCESS_SHARED mutex should be done in kernel, so kernel can remember a list of mutex the current thread owned, when the thread exits for whatever reason, kernel should reset the mutexes to a state and wake up threads waiting on these mutexes. It seems that Solaris does it in this way, another way is setting a mutex list pointer in kernel, but the list itself is in user address space, it is a bit tricky for kernel to figure out the list's intermediate states when the thread is killed and fix the mutex states, the benefit is locking and unlocking are fast because they are done by userland when possible, it seems Linux does it in this way. > 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