Date: Mon, 11 Jan 2016 19:06:25 +0000 From: Brooks Davis <brooks@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160111190625.GB79262@spindle.one-eyed-alien.net> In-Reply-To: <20151229184405.GY3625@kib.kiev.ua> References: <Pine.GSO.4.64.1512241338340.10649@sea.ntplx.net> <20151224191408.GA3625@kib.kiev.ua> <Pine.GSO.4.64.1512251310090.14902@sea.ntplx.net> <20151226105409.GH3625@kib.kiev.ua> <Pine.GSO.4.64.1512261151550.19056@sea.ntplx.net> <20151226234424.GJ3625@kib.kiev.ua> <Pine.GSO.4.64.1512271110450.23305@sea.ntplx.net> <20151228105157.GQ3625@kib.kiev.ua> <Pine.GSO.4.64.1512281118480.27627@sea.ntplx.net> <20151229184405.GY3625@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 29, 2015 at 08:44:05PM +0200, Konstantin Belousov wrote:
> On Mon, Dec 28, 2015 at 11:59:02AM -0500, Daniel Eischen wrote:
> > On Mon, 28 Dec 2015, Konstantin Belousov wrote:
> >=20
> > > Taking out the inlining bits from the David patch, or (which would I =
do,
> > > if doing this) just reimplementing it from scratch is easy enough and
> > > just require some time. I estimated this job to take between one and
> > > two weeks.
> >=20
> > I think a lot of David's patch is the renaming of all the
> > elements of the public structs to prepend '__'. I was thinking
> > it would be nice to have the public structs be something like
> > this:
> >=20
> > struct pthread_mutex_t {
> > uint32_t __x[IMPL_REQ + IMPL_SPARE + pad_to_CACHE_LINE_SIZE];
> > };
> >=20
> > and then have libthr override the definition. That would
> > make declaring PTHREAD_MUTEX_INITIALIZER, etc, a little
> > magical, but avoid a lot of needless churn in libthr.
> This is very good suggestion, I fully agree. There are some more details,
> e.g. it would be better to use uint64_t or explicit align attribute, to
> get proper alignment, but overall idea is sound, of course.
Based on our experiences with CHERI I'd suggest that the alignment of
opaque types be at least 128-bit to provide some future proofing. Even
with plenty of spare space (i.e. the giant jmpbuf on MIPS) incresing
alignemnt later adds complexity and opportunities for subtle breakage.
-- Brooks
--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWk/0wAAoJEKzQXbSebgfA7UUH/0KsCILGL3XgMqXJ5DHmQByO
CzRjLHA18RgSO9jweHd24NhVW3veHuueThyoWzh/aHM3CoA/NuX51cnVuSjjZTXu
5tx6/hlnjg8i3KUrcpweL/5U6J4QBsk8YjlVt0qIWuoRRwQCYd7dJPC5LVGw6XD+
UogZtYItXFUEjMB+9dtyV6PITTb1guPwjqikDiW3VycQpqO4sbqLa0HuI62lgadJ
XXRB0ttVCU9mUwz4U4DmqCKPo9pg+TEotLtETXOXPXlu3/7my/1sLuMAx8U0iZqE
v07sXFtCOYXZogSpWoGgSmySxX68LiaGDpd3SsDnY/VkRYpjBFxAjcFNsNfmR5w=
=4tyM
-----END PGP SIGNATURE-----
--+QahgC5+KEYLbs62--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160111190625.GB79262>