From owner-freebsd-threads@freebsd.org Wed Dec 23 19:48:59 2015 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EADCA50CEB for ; Wed, 23 Dec 2015 19:48:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3CBD61D68 for ; Wed, 23 Dec 2015 19:48:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 36F88A50CE8; Wed, 23 Dec 2015 19:48:59 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3676BA50CE7; Wed, 23 Dec 2015 19:48:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 036211D66; Wed, 23 Dec 2015 19:48:58 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id tBNJmu0b014361; Wed, 23 Dec 2015 14:48:56 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 23 Dec 2015 14:48:56 -0500 (EST) Date: Wed, 23 Dec 2015 14:48:56 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov cc: threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks In-Reply-To: <20151223190519.GU3625@kib.kiev.ua> Message-ID: References: <20151223172528.GT3625@kib.kiev.ua> <20151223190519.GU3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 19:48:59 -0000 On Wed, 23 Dec 2015, Konstantin Belousov wrote: > On Wed, Dec 23, 2015 at 01:27:35PM -0500, Daniel Eischen wrote: >> On Wed, 23 Dec 2015, Konstantin Belousov wrote: >> >> [ ... ] >>> Would the ABI modified to make the pthread_mutex_t large enough to >>> hold struct pthread_mutex, the rest of the implementation of the >>> shared mutex is relatively trivial, if not already done. >>> >>> Changing this ABI is very hard. libthr provides the symbol >>> versioning, which allows to provide compatible shims for the previous >>> ABI variant. But since userspace tends to use the pthread objects in >>> the layouts of the library objects, this causes serious ABI issues >>> when mixing libraries built against different default versions of >>> libthr. >> >> I think this is only if the libraries (or apps) pass pthread >> lock types between them, that one has initialized with one ABI >> but the other library uses another ABI. We should really >> exclude this as part of our ABI compatibility. > Applications commonly embed pthread locks into their objects, including > the exposed ABI in the third-party libraries. > > struct my_object { > pthread_mutex_t obj_lock; > ... > }; > > Changing the size of the pthread locks causes uncontrolled breakage of > the ABI for significant number of third-party code. If the application creates the object itself or allocates storage for it, basically, if it isn't opaque, yes. But we can bump port revisions for affected libraries (probably just searching /usr/local/include/... for pthread_mutex, pthread_cond, etc types to see possible problems. I did a search for the installed ports on my system and found a few that might cause problems. I think we're just putting off the inevitable. Do we not want to change our pthread sync types anyway, to get rid of an extra dereference per lock? To get rid of the hacks in libc, rtld, etc? If the answer is no, we never want to do that, then ok. -- DE