Data Model for Arduino running C++ and RTOS

Building a medium-sized application in C++ for an Arduino with multiple tasks that are supposed to run in parallel, I decided to take a look at freeRTOS (Real Time Operation System) which, as well is available for Arduinos (Mega2560 in my case).

Knowning that I will have approximately 5 tasks that need to operate on a common data base (not an actual Database), I decided to encapsulate the data in a central DataModel class.

Since all tasks run pseudo-multi-threaded, I need to synchronize the access to the DataModel. To prevent interference between the tasks, and to keep the entanglement as low as possible (mainly to be able to exchange single tasks / modules), I figured that all data exchange and communication between the tasks will happen via the DataModel (e.g. state variables)

What would be an appropriate approach for the DataModel class? Should all variables be static or should the class be a Singleton? Is it wise to use an Arduino HashMap implementation to canalize the access to variables over a single function and do the synchronization there (e.g. with a monitor for each variable or via some kind of AtomicInteger), or is there a better way to take care of that (see code below for beeter understanding)?

I know about the different techniques of making an application thread-safe (mutex, semaphore, monitor, atomicInt). The question is more aiming on the optimal "software engineering" solution under consideration of platform (Mega2560) and framework (freeRTOS).

public:

int getIntValue(char* name) { if(intData.contains(name)) { return intData.get(name); } else return NULL; }

bool setIntValue(char* name, int expect, int update) { if(intData.contains(name)) { bool result = false; lock.lock(); if(intData.get(name) == expect) { intData.get(name) = update; result = true; } lock.unlock(); return result; } else { return false; } }

EDIT: Reading about the "FreeRTOS Queues" for Inter-Task communication, it seems to be the better approach, rather than storing all data queueable data (display commands, radio communiaction messages, console logs) in a DataModel class. These would have been the major load cases anyway... Everything else are just some controlling bits for the program flow

IMHO don't use anything as complex as an RTOS.

Just use the techniques in the demo Several Things at a Time

...R