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

Delete a task that waits for a binary semaphore

Posted by apica on January 23, 2017

Hi,

I'm developing a middle layer between a peripheral an upper layers, and this middle layer has a binary semaphore.

The upper layers (threads) call the "Request" function of the middle layer, this takes the binary semaphore (xSemaphoreTake) to allow only one access to the peripheral at a time. Once the use of the peripheral is finished, the upper layer executes the "Release" function of the middle layer that releases the semaphore.

Now suppose the case that the semaphore is taken, and other upper layer (thread) executes the Request function. This will lead the thread to be waiting for the semaphore. If this thread is externally deleted, will the semaphore keep correct values? Is it safe to do?

Thank you


Delete a task that waits for a binary semaphore

Posted by heinbali01 on January 23, 2017

I hope I understand your question:

When a task is being killed, the OS won't know which semaphores were taken by the task. I my opinion, it is more transparent to let a task kill itself. So if you want to kill a task, send it a message or set some flag to which it will respond. The task will know perfectly which resources it has claimed and what to do to terminate properly. Regards.


Delete a task that waits for a binary semaphore

Posted by apica on January 23, 2017

Thank you Hein.

Yes, it would be easier if the task terminates itself and releases all the resources but I'm not sure if it is compatible with the low power. The xSemaphoreTake it was supposed to be blocked "forever" until the resource became available.

From your reply, I guess you are saying to avoid the "forever" semaphore and check from time to time a flag (or something else) to know if it has to terminate itself. Is that right?

Thank you


Delete a task that waits for a binary semaphore

Posted by rtel on January 23, 2017

Are you asking what happens if the middle layer task gets deleted while it has the semaphore, or what happens if a higher level task that is blocked waiting for the semaphore gets deleted? If you are just talking about the latter case, where a task attempts to take a semaphore, blocks, then gets deleted before it unblocks, then nothing happens - everything will be fine. The task will get deleted and removed from the list of tasks waiting for the semaphore. This holds for binary semaphores but not necessarily other types of semaphore.


Delete a task that waits for a binary semaphore

Posted by richard_damon on January 24, 2017

I generally find that I don't need to delete/recreate tasks, and that people doing this tend to be thinking much more of a unix type model with full processes, and not a micro-kernal with tasks (which are much more like threads on bigger machines). The key thing is that if you are going to delete a task, you are almost certainly going to also be recreating the task later, and without a lot of careful analysis, you need to be prepared for the create task to fail. The major way to be sure that the create will succeed (other than not deleting in the first place so you don't need to recreate) is to have a lot of memory, but then there isn't much need to delete the task in the first place.

Because tasks are NOT full blown processes of the unix ilk, you need to take a lot of care to be sure the task is in a proper state before deleting it (so you don't lose resources), which tends to make it simplest that if you do delete tasks, it is them self-deleting, otherwise it is very hard to avoid race conditions.


Delete a task that waits for a binary semaphore

Posted by apica on January 24, 2017

Yes, it was the second case (isn't easy to explain).

Thank you!


Delete a task that waits for a binary semaphore

Posted by apica on January 24, 2017

Hi Richard, thank you for your reply.

I understand your aproach. The main goal to delete / suspend / block a task is to enter in a low power mode. When the system decides to stop the device, it has to tell to the modules to stop working.

If a "release" function is executed from a upper layer, this function needs to stop the thread somehow and all its used resources (semaphores, queues, perihperals, ..).

So, to set a bigger scope to thre problem: How would you deal with low power while using freeRTOS based systems?

Thank you very much.


Delete a task that waits for a binary semaphore

Posted by richard_damon on January 24, 2017

A task that is block indefinately on a semaphore or queue will not prevent the system from entering low power mode (the key is indefinately or at least for a long time), This generally SHOULD be the normal state for any task that doesn't have something immediately to do anyway.


Delete a task that waits for a binary semaphore

Posted by rtel on January 24, 2017

A task that is block indefinately on a semaphore or queue will not prevent the system from entering low power mode

More so - that is exactly when the system WILL AUTOMATICALLY go into low power, if configUSETICKLESSIDLE is set to 1 (on ports that implement it).


[ 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