[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170706163320.104c9d05@inria.fr>
Date: Thu, 6 Jul 2017 16:33:20 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: move to a proper __lock_t type
Hello,
On Wed, 5 Jul 2017 17:41:50 -0400 Rich Felker <dalias@...c.org> wrote:
> One minor concern: if we do make it a struct type, there are possibly
> formal aliasing issues with having it embedded in any of the public
> pthread types (cond vars, maybe barriers?) without a public
> definition. Perhaps it should be an int array typedef (length 1) or
> just a typedef'd int?
Right, I already have looked into cond vars and have a patch for
that. At the time we were doing the C11 thrd stuff, we already
discussed that, and in fact I think now would be the time to have that
improved, too. The current implementation there, is already somewhat
similar in strategy to the new algorithm.
Hm, this would again imply that we wouldn't be able to stick a
volatile into the type, and so we would even loose the volatile that
we have now for all the "lock" variables.
So, I would go for
typedef volatile int __lock_t[1];
after you merged the new algorithm.
For cond variables the __lock/__unlock interfaces then would still
"work", modulo the problem that the underlying int is not a veritable
volatile. But that is the situation for this code now, anyhow.
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
