[NO REPLY] Handling concurrent operations (rev #2, 2018-1-15)

Obsolete material.
User avatar
Site Admin
Posts: 14465
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1080 times
Been thanked: 924 times

[NO REPLY] Handling concurrent operations (rev #2, 2018-1-15)

Postby Giovanni » Fri Dec 15, 2017 10:27 am

The language requires to declare functions that can be executed concurrently using the async keyword. This keyword imposes restrictions about how data can be accessed.

Asynchronous functions can only access constant global variables and automatic variables and can only access pure functions or functions marked with async, this is the safest use for memory: sharing nothing.

Access to global variables has to be enabled using an exclusive access keyword that enforces mutual exclusion on the data, such keyword can be defined as follow:

Code: Select all

worddef exclusive async <isr> {
} my_access;

From within compound statements marked with that word it is possible to access variables marked with the same keyword and call functions marked with the same keyword.

Code: Select all

my_access int i = 0;

my_access void increase_counter(void) {
  i = i + 1;

void async <isr> my_async_function(void) {
  /* here global variables and calling generic functions is not possible */
  my_access {
    /* from here I can access variables marked as my_access and call marked functions too */

void my_sync_function(void) {
  int i_local;

  my_access {
    i_local = i;
    i = i - 1;


As you can see it is only possible to access shared variables using a exclusion method defined by the my_access construct. The mutual exclusion method can be anything, it is part of my_access definition and associated to the async <class>:
- Disabling interrupts.
- Using an HW semaphore.
- Using an RTOS primitive like mutexes.

The language only gives an instrument to enforce safe access from asynchronous entities. In a system there could be several different methods for accessing shared resources or groups of shared resources using different instances of the same method (for example multiple mutexes).

Note that the above constructs know nothing about IRQs, tasks, mutexes etc. The language only enforces access rules for asynchronously updated variables. Safer C is not imposing a specific threading model nor API nor framework, the underlying mechanisms could be anything from HW mechanisms to an underlying RTOS or something entirely different.


Return to “obsolete”

Who is online

Users browsing this forum: No registered users and 1 guest