From owner-freebsd-current@FreeBSD.ORG Wed Jan 6 01:11:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 368EA106566B for ; Wed, 6 Jan 2010 01:11:54 +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 0E3ED8FC0C for ; Wed, 6 Jan 2010 01:11:54 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o061Bq43023967 for ; Wed, 6 Jan 2010 01:11:53 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4B43E358.609@freebsd.org> Date: Wed, 06 Jan 2010 09:11:52 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: process-sharable pthread synchronous objects X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 01:11:54 -0000 I want to go further to make some pthread synchronous objects process-sharable, do you guy think it is worthy ? except mutex and condition variable, others like rwlock and spinlock are relative simple. The pthread mutex is complex, especially they introduced robust mutex type in new specification, I don't know if we need change code a lot or a little. The current mutex implementation is not fork-friendly, because we use global thread ID as mutex owner, if a process is forked, the process-local mutex is unusable by thread in child process, current we fixed the mutex ownership for child process in fork() by libthr. The thread ID(global or local) is needed because I want make priority-inherited mutex as fast as normal mutex in non-contention case, only when the thread is blocked it will enter kernel and find the owner of the mutex, and boost the owner's priority. to find the owner, it need to use thread ID. Otherwise, I can not find a way to make priority-mutex as fast as normal mutex. For process-shared mutex we really need to use global thread ID, for process-local mutex, if we have process local thread ID, then we only need to change code slightly. Still don't know how a mutex can be robust in shared-memory model. ;-) Regards, David Xu