Re: sem_getvalue conformance considerations

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

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

Am Dienstag, den 26.08.2014, 22:33 -0400 schrieb Rich Felker:
> What if we try to get fancy and subtract waiters from __val[0]?
> Unfortunately we can't necessarily read __val[0] and waiters
> (__val[1]) atomically together,

Doing the correct thing is always fancy :)
Sure that this depends on the architecture, but where this is possible
we should just do that, this is the semantically correct value.

On i386 and follow ups 64bit atomic read should always be possible,
and if I remember correctly the arm arch that I touched once had such
a thing, too.

For once the gcc extensions for builtins have easy to use feature test
macros. If you'd have the sem_t changed to a union with alternative
__vall long's, something along the line

#if defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8) && defined(__ATOMIC_ACQUIRE)
uint64_t combined = __atomic_load_n(&s->__vall[0], __ATOMIC_ACQUIRE);
#else
... fallback ...
#endif


> so it's possible that one is outdated
> by the time we read the other, such that the resulting difference is
> not the correct formal semaphore value at any time during the
> sem_getvalue call.

On arch where atomic read of these two values together is not
possible, this is the best approximation that you can get. On these
archs there is simply no precise moment in time for that feature
because the sequence points are not synchronized between the different
threads. Nobody can ask you to return an exact value for a concept
that is not well defined.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: 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: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]