From owner-freebsd-threads@FreeBSD.ORG Tue Mar 31 01:05:33 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 12A2E106566C for ; Tue, 31 Mar 2009 01:05:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outi.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id ECE968FC22 for ; Tue, 31 Mar 2009 01:05:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id ABE0BCD38; Mon, 30 Mar 2009 17:55:23 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id EF0C32D606A; Mon, 30 Mar 2009 17:55:16 -0700 (PDT) Message-ID: <49D16A0F.4000404@elischer.org> Date: Mon, 30 Mar 2009 17:55:43 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Randall Stewart References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <49D136B1.6060809@delphij.net> <78DBBDDA-5A39-4CEB-8289-F36EFB96461D@lakerest.net> In-Reply-To: <78DBBDDA-5A39-4CEB-8289-F36EFB96461D@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: threads@freebsd.org, d@delphij.net Subject: Re: A mutex for inter-process ;-) 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 01:05:33 -0000 Randall Stewart wrote: > >> >> I think davidxu@ deischen@ and julian@? >> >> BTW. How do you handle with one process exit (abnormally) without >> releasing the mutex? Just curious :) > > I have a couple of ways of dealing with this.. > > 1) Of course the initialization routine calls atexit() to get a > "cleanup handler" in place. this is not really sufficient for a system supplied service. > 2) Often times, of course, this can fail e.g. you get a SIGSEGV.. > or some such. When you attach the memory, an audit is done. The > audit will validate that the pid is still alive and has the > particular tid in it. Of course this is not 100% but as long as the > tid's have not rolled over it should work. The function is also > public (need to add that and many things to the manual pages ;-D) > so that onecan call it whenever one wants :-) TIDs do roll over the last I looked.. (this may have changed) did you say man page? goodie.. lets' see it.. There have been a lot of IPC and mutex implementations but the trick always comes with the requirement that they handle process/thread death. David has done some recent work in this space.. > > I will ping Julian and the others... >