On 07-01-19 11:21, Juan Ignacio Carrano wrote:
Hi Kees,
Hey Juan,
On 1/4/19 10:18 PM, Kees Bakker wrote:
In a lot of our code sched_active_thread is converted into
a non-volatile pointer. Is that correct? Here [1] it is described
that such conversion is undefined behavior.
My understanding is that `sched_active_thread` is volatile in a thread
context, but not in the kernel context. Therefore I thought that
discarding the qualifier in code that runs in the scheduler should be
OK, although a bit dirty. Now, if you tell me it's undefined behavior
then it is NOT OK.
I had thought of two ways to fix this:
* Linker-level aliasing: define `sched_active_thread` once (in the
scheduler, as non volatile) and declare it as `extern volatile` in
those headers that are seen by user applications, and as `extern` in
headers seen by the kernel.
* C-level aliasing: redefine sched_active_thread as a union of a
volatile and non-volatile.
AFAICT neither of those ways of accessing should result in undefined
behavior, as there as no casts being performed. What do you think?
My main concern is: who made it volatile in the first place? And what
was the
reasoning behind it? Volatile is one of the least understood properties
of the
C language (my personal opinion). I'm hoping that the volatile was not
just thrown
in because it feels good when doing threads. And in other places the
volatile is
ignored, hopefully for a good reason (optimisation is _not_ a good reason).
Your two alternatives result in basically the same situation as the
casted pointer.
The problem will always be that we need someone to judge whether the cast
is correct (in the case of the union, do I need the volatile or the non
volatile
version).
--
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
