• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 22 subscribers
  • Views 1692 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

    Macros (as in #define) is normally a thing to avoid if possible.
    It's too easy to give them side effects that wasn't intended and that isn't visible without looking at preprocessed sources.

    When possible, it is way nicer to implement inline functions, since you can then get the same type checking etc as for normal functions, but still get the compiler to inline the actions.

    In many situations, it is meaningful to use C++ even when the official design does not call for a fully object-oriented application.

    Things like:

    bool my_function(...) {
    ...
    {
        CLockWrite synchronize(my_lock);
        res = do_something();
        if (!res) return false;
    }
    ...
    return true;
}


    Is too valuable to ignore. A constructor to lock a resource, and the destructor to release the lock means the code has a clearly protected section of code without any chance of accidentally forgetting to release the resource lock.

Reply
  • 0 in reply to Andrew Queisser

    Macros (as in #define) is normally a thing to avoid if possible.
    It's too easy to give them side effects that wasn't intended and that isn't visible without looking at preprocessed sources.

    When possible, it is way nicer to implement inline functions, since you can then get the same type checking etc as for normal functions, but still get the compiler to inline the actions.

    In many situations, it is meaningful to use C++ even when the official design does not call for a fully object-oriented application.

    Things like:

    bool my_function(...) {
    ...
    {
        CLockWrite synchronize(my_lock);
        res = do_something();
        if (!res) return false;
    }
    ...
    return true;
}


    Is too valuable to ignore. A constructor to lock a resource, and the destructor to release the lock means the code has a clearly protected section of code without any chance of accidentally forgetting to release the resource lock.

Children
  • 0 in reply to ImPer Westermark

    @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.

  • 0 in reply to @Marc Crandall

    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.

  • 0 in reply to ImPer Westermark

    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.