[riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored

Kees Bakker kees at sodaq.com
Mon Jan 7 21:19:48 CET 2019


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


More information about the devel mailing list