Queuing Pointers

Queuing pointers is different from queuing copies of the data in the sense that for pointers: 1. “The owner of the RAM being pointed to is clearly defined.” 2. “The RAM being pointed to remains valid.” In the book, it is mentioned that: “A pointer should never be used to access data that has been allocated on a task stack. The data will not be valid after the stack frame has changed.” Does this mean that I need to the data on the heap using malloc? I understand that a task looks like this (it never exits): ~~~ void task(){ int x; while(1){ … } } ~~~ The variable x is allocated on the task stack, correct? However a task never exists, meaning its stack reamins for the lifetime of the program. Can I still use the variable x as a pointer to access data? Thank you

Queuing Pointers

Basically yes. But as documented you have to ensure that the task resp. the scope of the local variable is never exited, which makes it invalid. Also be aware that the compiler (optimizer) has no idea about tasks and might do interesting things with local/stack variables i.e. using CPU registers instead of allocating space on the stack. However, probably when using a pointer of a local variable as argument of a non-inlined function you can successfully enqueue the address of this local variable.

Queuing Pointers

One big thing to remember when passing data as a pointer is that you don’t get a snapshot of the value the pointer points to, but whatever happens to be stored in memory at the time of access, which isn’t what the programmer normally expects at quick thought. Also, since now the data is available to multiple tasks at once, the programmer needs to be prepared to handle all the syncronization issues for access. Generally, when sending data via a pointer, you want to at least conceptually think of the data as being owned by the task that has been sent the pointer, and no longer by the task that sent it, which is a bit hard to do mentally when it is a local stack variable.

Queuing Pointers

One big thing to remember when passing data as a pointer is that you don’t get a snapshot of the value the pointer points to, but whatever happens to be stored in memory at the time of access, which isn’t what the programmer normally expects at quick thought. Also, since now the data is available to multiple tasks at once, the programmer needs to be prepared to handle all the syncronization issues for access. Generally, when sending data via a pointer, you want to at least conceptually think of the data as being owned by the task that has been sent the pointer, and no longer by the task that sent it, which is a bit hard to do mentally when it is a local stack variable.