Selected Documentation for Messaging-Cells Library
Memory features

Module describing memory features. More...

Module describing memory features.

In-workeru RAM partitions

The RAM memory of each workeru is divided in:

  1. Kernel code.
  2. Stack.
  3. Module code. See Loading features
  4. Dynamically allocatable memory.

The sizes and location are configurable in the GNU link script. See Linking features.

Dynamic memory

The in-workeru dynamic memory is handled in a two fold way:

First time heap allocation

The first time an object is allocated the library calls external code (off-workeru) of the umm_malloc allocator.

Reusing objects

Objects are never really expected to be freed (umm_free call) under normal use of the library. They just get acquired (see for example cell::acquire) ; and when finisehd using them, they should call the agent::release method to get inited and put in a one-per-class double linked list (grip) of available objects (see agent::get_available virtual method).

The one-per-class acquire and the agent::release are small footprint methods runned from in-workeru memory (as opposed to the umm_malloc functions) that can be used in the user's high performance code.

This double folded approach to memory managment also helps to avoid bad referencing of objects because a cell might have been agent::release d but the reference is still valid, so the code will not behave as expected (there is an error) but it will not hang.

Functions like cell::separate cell::acquire are provided for base classes but the user is expected to use macro MCK_DECLARE_MEM_METHODS and macro MCK_DEFINE_MEM_METHODS to declare and define these functions for derived classes. The macro MCK_DEFINE_ACQUIRE_ALLOC can also be used for classes of objects that will not get agent::release d and therefore do not declare an available list.

Eating Philosophers

The classical example eating philosophers for synchronizing concurrency is given in the philo.cpp example program.