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




Loading

Can higher priority task give a mutex it does

Posted by Paul Coleman on September 14, 2012
I have a high priority error recovery taks which needs to clear all the mutexes and semaphores of lower level tasks, so that it can resume in a known state. Is it okay for this higher level task to give a mutex that it didn't take in the first place so that it will be available in the lower level tasks when they need it to syncronise access to a resource?

Thanks.

RE: Can higher priority task give a mutex it does

Posted by Richard Damon on September 14, 2012
I don't know if FreeRTOS will have a problem with this, but from the way you phrase your question, I suspect your program will. Having one task release the mutex that another task has aquired becuase it has detected a "problem" is almost always wrong. The issue being that the task that had the mutex will still think it has it, and will continue accessing the resource, possible with a contention issue. If it was ok to access without owning the mutex, then the mutex wasn't needed anyway. The most like result is changing a problem that you know, but might not know the cause of, into a problem that you have no idea what it is and how it might present itself.

The options for the high priority error recovery task tends to be things like:
1) Reboot the system so everything come up into a know state, perhaps passing it some information to allow some activity to be resumed with a reduced loss of state to the outside world.

2) reboot a subsystem. This does require careful design that the sub-system reboot can't contaminate the rest of the enviroment.

3) The error recovery task just sends messages to the various tasks asking them to clear their state and release the resources, and if this doesn't work in a given time, fall back to one of the above methods.

It is of course much better to have designed the task to not be able to "fail" in the first place, so that they naturally recover from the problems that might arise. If they are doing their job right, then generally an error that requires a "recovery task" will have two options based on system reqirements, reboot or halt, as it means you are now in a state that you decided was impossible and thus you can have no confidence in the current state of the machine.

The individual task is the one that most knows what is happening, and how to recover. For it to not do that is a spec/design issue, which can not reliably be fixed with a band-aid like releasing mutexes for different tasks then that took them.

Semaphores are perhaps a bit different, but still tend not lend themselves to an error recovery task. If being useds a mutex, all of the above tends to apply, but the FreeRTOS software is unlikely to have an issue as semaphores are not naturally limited to the giver being the previous taker. If the semaphore is for a more traditional producer/consumor interaction, then the error recovery task can of course gve the semaphore, IF it fulfills the contract associated with that semaphore, but the question then comes, why isn't the normal producer providing the data?

RE: Can higher priority task give a mutex it does

Posted by Paul Coleman on September 14, 2012
Thanks for the reply.

I do have HALT and REBOOT situations already but this is for a situation that I can potentially recover from if I can reset and restart about 6 tasks. Each one of those tasks is using semaphores and there is a single mutex shared by 2 tasks to synchronise access to a resource. It has to be a mutex and when the recovery task gets started one of those two tasks may or may not have taken the mutex. The tasks are state machines where the transition between states is governed by semaphores and I need to force all the tasks into a known state. The way I've done that is in the error recovery task I loop round giving each task all the possible semaphores it needs to progress through the states until it transitions to the recovery state. Once it gets to the recovery state it suspends and the recovery task then resumes all those suspended tasks when it's finished doing its stuff.

It does appear to work as it is...

RE: Can higher priority task give a mutex it does

Posted by Richard on September 14, 2012
Semaphores, other than mutex type semaphores, should not be too problematic, but I would be careful about giving a mutex from a task that does not own it. Mutexes, unlike other semaphores, note the mutex holder in their structures to allow priority inheritance and disinheritance.

Regards.


[ 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