Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training


critical section or semaphores? to protect a large list of variables

Posted by seanbzd on June 21, 2015

I have a large list of variables that can be read or written to by multiple tasks. One of the Task that updates some of these variables is triggered off(using semaphore take/give)of an interrupt when new data is available. Option 1: Create a ReadVariable() and WriteVariable() functions that use a critical section to protect the variable and the only way to access the variable. Option 2: Create a semaphore for "each" variable. Have multiple functions in a class that may be accessing these variables directly but uses the specific semaphore associated with that variable to read/write that variable. How performance/memory intesive is creating and using a semaphore because in this method, each variable has its own semaphore.

Any suggestions/advice? Thanks.

critical section or semaphores? to protect a large list of variables

Posted by rtel on June 22, 2015

From the information you have provided I would not recommend creating a semaphore for a single variable - only if you need to update more than one variable at once without interruption from other tasks of interrupts (ie. variables must all be consistent with each other, rather than on an individual basis).

You could have a readvariable function that uses a critical section. Whether the writevariable function also needs a critical section depends on how the variable is updated. If the variables are just written to directly, then they probably don't need a critical section - if on the other hand writing to a variable requires a read-modify-write operation (for example variable += 2; or variable++;) then that will need a critical section too.


critical section or semaphores? to protect a large list of variables

Posted by richard_damon on June 22, 2015

A key thing to look at is how long does a task need "ownership" of the variables to do what is needed. If you can do the operation in a few operations (and the length of a "few" is dependent on how much slack you have in your required interrupt latency) then a critical section is a good way to go. If the time is a bit too long for a simple critical then a mutex (I would prefer it over a semaphore to add the priority inheritance) over the variables could make sense. If you have contention over different unrelated variables, then breaking things down into smaller groups might make sense (task1 & task2 need variables var1 and var2, while task3 & task4 need variables var3 & var4), you likely don't need a mutex for EACH variable, but for variable groups.

Another observation. if the access to a variable is naturally atomic (the items are natural word sizes for the processor), and you aren't concerned about inter-variable interactions (i.e. a change to var1 needs a change to var2), then reads likely do not need to be protected at all, and writes only if they are a read-modify-write with multiple writers. If there are inter-variable interactions then you definitely don't want a mutex for a single variable, but for the cluster that is updated together.

[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists