• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 22 subscribers
  • Views 1677 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RTX - Data integrity

@Marc Crandall

Hello,

I have a pretty generic question about embedded RTOS systems and data integrity.

I'm using RTX and I have several instances of structures that need to be read/written from several task.

As an example, take:

struct demo
{
int var_a;
int var_b;
int var_a_max;
int var_a_min;
}

If I have several global demo instances, what is the 'danger' in allowing several tasks to R/W the global instances?

I understand that the values could change mid execution but say you implemented a simple "lock and copy" procedure before each tasks loop execution.

Would mailboxes really be required in this case?

Further, what if all tasks only ever read/write one of the fields (var_a) do you even need a lock and copy or would simple copy do?

Finally, say I did want to implement a generic mailbox pattern so that any task could request a copy from a managing task and send updates to a managing task. Does any one have an example of such a pattern?

Thanks. I appreciate any discussion and opinion on this topic, I'm looking for the most efficient (time and complexity) way to proceed while still being 'safe' in my logic.

M

Parents
  • 0 in reply to Andrew Queisser

    Thanks again guys.

    @Tamir - I'm not sure I would describe your example situation as register corruption, but I get your point.

    In my situation I think it will make most sense to have 'task 2' deal with any undefined situation.

    @Andrew - Yes, abstraction is very important to me. This is something I've come to appreciate over the last decade. On this project alone we have already changed the hardware once and switched a (important) 3rd party library component. I very much like well defined abstraction layers. (HAL, DAL...)

    For anyone else reading this thread, based on the discussion above, my plan is to use synchronization mutex objects to lock reads and writes (and some algorithm sections) of some global data.

    What I did that really helped me come to this decision was make a diagram with all the 'global objects' and I illustrated which task write to and which read from each global object. With this diagram synchronization became very clear.

    Thanks.

    M

Reply
  • 0 in reply to Andrew Queisser

    Thanks again guys.

    @Tamir - I'm not sure I would describe your example situation as register corruption, but I get your point.

    In my situation I think it will make most sense to have 'task 2' deal with any undefined situation.

    @Andrew - Yes, abstraction is very important to me. This is something I've come to appreciate over the last decade. On this project alone we have already changed the hardware once and switched a (important) 3rd party library component. I very much like well defined abstraction layers. (HAL, DAL...)

    For anyone else reading this thread, based on the discussion above, my plan is to use synchronization mutex objects to lock reads and writes (and some algorithm sections) of some global data.

    What I did that really helped me come to this decision was make a diagram with all the 'global objects' and I illustrated which task write to and which read from each global object. With this diagram synchronization became very clear.

    Thanks.

    M

Children
No data