From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: pthread_mutex_lock() and Xenstored Date: Thu, 13 Sep 2007 17:03:09 +0200 Message-ID: <20070913150309.GA21282@snarc.org> References: <05c801c7eb94$850ae780$9a010a0a@eeyore> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <05c801c7eb94$850ae780$9a010a0a@eeyore> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Peter Teoh Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Fri, Aug 31, 2007 at 01:51:18PM +0800, Peter Teoh wrote: > pthread_mutex_lock() are not async-signal safe (ref: > http://www.gelato.org/pdf/Illinois/gelato_IL2004_libatomic_boehm.pdf) > but I still see that it is used extensively in xenstored > implementation (eg, xs.c). xs is the client part of the xenstore protocol. it's not used in xenstored (the daemon). > Moreover, pthread_mutex_lock() suffered a higher performance penalty > than other synchronization option. For a one-time effort like domain > creation this is ok, but Xenstore is used repeatedly to access data, > and therefore performance could potentially be enhanced. > > Does all these sound logical? Not really. xenstored is single threaded and has a file-backed-storage anyway, so most of the time you're going to wait for that. I expect the pthread_mutex_lock to be insignificant compared to the time waiting for xenstored to reply. Also the xs interface is not meant to be use massively in parallel. Cheers, -- Vincent Hanquez