[riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored
kees at sodaq.com
Mon Jan 7 21:19:48 CET 2019
On 07-01-19 11:21, Juan Ignacio Carrano wrote:
> Hi Kees,
> 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  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
reasoning behind it? Volatile is one of the least understood properties
C language (my personal opinion). I'm hoping that the volatile was not
in because it feels good when doing threads. And in other places the
ignored, hopefully for a good reason (optimisation is _not_ a good reason).
Your two alternatives result in basically the same situation as the
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
More information about the devel