Re: move to a proper __lock_t type

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

Hello,

On Wed, 5 Jul 2017 17:41:50 -0400 Rich Felker <dalias@libc.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 ::

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]