[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 19 May 2015 15:57:00 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl <musl@...ts.openwall.com>
Subject: trouble spots for atomic access
Hello,
by forcing the compiler to detect consistency checks for
atomics as I mentioned earlier, I detected 5 trouble spots. The first
four are relatively clear:
- a_and and a_or interfaces on i386 and friends are not consistent
with the remaining archs. They have `volatile void*` for the
arguments and then do a gratuitous cast to `int*`. As far as I can
see just using `volatile int*` as for the other archs works fine.
- pthread_once_t should always be volatile
- pthread_spinlock_t should always be volatile
- pthread_barrier needs atomic increment
The fifth troubles me a bit. It concerns __timedwait and
__timedwait_cp. These both are mostly used with a first argument addr
that is atomic. This makes sense, since addr then is passed to a call
to futex, which internally might do some atomic operations. Now there
is one call that doesn't pass something that is otherwise seen as
atomic, namely line 14 in pthread_join.c. It reads as
while ((tmp = t->tid)) __timedwait_cp(&t->tid, tmp, 0, 0, 0);
So is the task id here to be seen as atomic, or not? Will updates to
that field that are not atomic (and maybe optimized in some sort) be
able to mess up the futex call?
Thanks
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 ::
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
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.
