From owner-freebsd-threads@freebsd.org Fri Feb 19 15:08:37 2016 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 D6F84AADA3F for ; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 BB499139A for ; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B9077AADA3D; Fri, 19 Feb 2016 15:08:37 +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 9EB5FAADA3B; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4702C1399; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1JF8Sei034403 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Feb 2016 17:08:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1JF8Sei034403 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1JF8RRu034402; Fri, 19 Feb 2016 17:08:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Feb 2016 17:08:27 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160219150827.GW91220@kib.kiev.ua> References: <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <20160217164541.GM91220@kib.kiev.ua> <20160218153256.GS91220@kib.kiev.ua> <20160219003255.GU91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Fri, 19 Feb 2016 15:08:38 -0000 On Thu, Feb 18, 2016 at 09:31:44PM -0500, Daniel Eischen wrote: > On Fri, 19 Feb 2016, Konstantin Belousov wrote: > > > On Thu, Feb 18, 2016 at 12:09:59PM -0500, Daniel Eischen wrote: > >> On Thu, 18 Feb 2016, Konstantin Belousov wrote: > >>> But base system provides C++ runtime for ports and I suspect that libc++ > >>> depends on the libthr ABI. Even jemalloc depends on libthr ABI. So > >>> changing only the base ABI is probably impossible, from the first look > >>> the switch like WITH_LIBTHR2_DEFAULT would be a flag day. Anyway, this > >>> must be considered carefully during the later stage of the libthr2 > >>> development, right now it is rather empty speculation on my side. > > This paragraph is relevant for my answer below. > > > >> > >> I would think partially inlined objects (still a pointer inside) > >> could be made in libthr (not libthr2) by default for 11.0 (or 11.x). > >> So that the only change is the size of the objects, not anything > >> else. The only breakage would be layout related. > > > > Structure size is part of the library ABI, when the structure is exposed > > to user, it cannot be increased without consequences. > > > > Changing the size of the libthr objects changes layout of the objects > > embedding the locks. Doing > > class MyLock { > > private: > > pthread_mutex_t m_lock; > > const char *name; > > }; > > is the common and very popular practice. With the change proposed to > > libthr.so.3, you get subtle and sudden ABI breakage for all libthr > > consumers as well. In particular, it would affect libc (jemalloc) and > > libc++. Depending on the variant of headers used for the compilation, > > you get different layout for user structures. > > libc is part of FreeBSD, so it would be recompiled for the new > size. I was also assuming library version bumps. Increasing the structures sizes (and bumping versions) would - break ABI - invalidate all the work which was done by people from the FreeBSD 7.x time to keep the ABI stable, by writing shims, by adopting changes to provide compatibility, and by testing the compatibility without any benefit of a new feature. It would be only promised to provide a new feature sometime in the 11.x scope. My immediate goal is to get the published patch committed. After that, I want to look at the implementation of the robust mutexes. I hope that this would be done for 11.0, but if not, it should be mergeable. The libthr2 stuff, by which I call everything related to inlining, should be started after that.