We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
@Per - yes, I really like this kind of thing when using C++. I hadn't thought about using a simple C++ class in my C app but I suppose it's a good idea. Do you than compile your entire application as C++? Does this not link in a the C++ runtime? (Unneeded stuff like heap management, RTI...)
Macros certainly have some issues but I would argue, like you, that they to are too valuable to ignore. Inline functions become slightly less useful across translation units but yes are certainly a good strategy in some cases.
Different compilers have different rules.
You can normally turn off RTI.
You normally don't get the extra heap code as long as no code plays with new and delete (or you replace them).
One of the original design goals (at least before C moved ahead and stopped being a strict subset of C++) was to allow a developer to take a C program and recompile as C++, and then decide what parts of the code to rewrite to use an object-oriented model.
Compiling all C code as C++ also means that you get the type-safe linking unless you explicitly wants symbols to use the C naming convention for external symbols.
at least before C moved ahead and stopped being a strict subset of C++
C never actually was a proper subset of C++. And that's because C++, not C, moved ahead and hast been doinng so ever since it was first given that name.