[RTOS Support] How early can I use a mutex?

Quality RTOS & Embedded Software

About Contact Support FAQ Download

Menu

Quick Start

Supported MCUs

PDF Books

Trace Tools

Ecosystem

Quick Start Guide

Support Forum

⇓ Download Source ⇓

FreeRTOS+ Ecosystem

FreeRTOS+TCP:
Thread safe TCP/IP stack

SafeRTOS:
TUV certified RTOS

OpenRTOS:
Commercial Licensed RTOS

Fail Safe File System:
Ensures data integrity

FreeRTOS BSPs:
3rd party driver packages

Trace & Visualisation:
Tracealyzer for FreeRTOS

CLI:
Command line interface

WolfSSL SSL / TLS:
Networking security protocols

RTOS Training:
Delivered online or on-site

IO:
read(), write(), ioctl() interface

FreeRTOS+ Lab Projects

FreeRTOS+POSIX:
POSIX threading API

FreeRTOS+FAT:
Thread aware file system

FreeRTOS Support Archive

The FreeRTOS support forum is used to obtain active support directly from Real Time Engineers Ltd. In return for using our top quality software and services for free, we request you play fair and do your bit to help others too! Sign up to receive notifications of new support topics then help where you can.

This is a read only archive of threads posted to the FreeRTOS support forum. The archive is updated every week, so will not always contain the very latest posts. Use these archive pages to search previous posts. Use the Live FreeRTOS Forum link to reply to a post, or start a new support thread.

[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2009 Threads]

How early can I use a mutex?

Posted by M Beronius on October 2, 2009

Are there dependencies for mutexes ? I'd like to use a mutex very early on in boot process (main), prior to starting threads. Is this allowed? (the mutexes are created, but vTaskStartScheduler() has not been called)

((I know that the concept of mutexes are not needed at this point, but it makes my code nicer, if I can use existing functions this early in the startup))

Thanks
Micael

RE: How early can I use a mutex?

Posted by Dave on October 2, 2009

You can call functions that do not attempt to block or cause a context switch.

RE: How early can I use a mutex?

Posted by M Beronius on October 2, 2009

Excellent

Thank you for this quick response!!

- Micael

RE: How early can I use a mutex?

Posted by mizer on February 22, 2010

So just to be clear - it is safe to call 'xSemaphoreTake' and 'xSemaphoreGive' -after- the Mutex has been created but -before- the scheduler has been started? I find myself in the same position as the original poster.

Suggestion: perhaps a list of which OS API functions are safe to use before the scheduler has been started would be handy/interesting. Probably not many of them are! I have seen in writing that taskENTER_CRITICAL() and EXIT are safe to use. I wonder which others?

RE: How early can I use a mutex?

Posted by MEdwards on February 22, 2010

I think the semaphore give and take functions will be ok to use before the scheduler is started provided you do not try and block while giving or taking. Keep the block time at zero.

RE: How early can I use a mutex?

Posted by mizer on February 24, 2010

Sorry I've been sidetracked for a few days.

Thanks edwards for your input.

Richard, May I ask that you please definitively state if it is okay to call the xSemaphore Take and Give functions after creating the semaphore but prior to starting the scheduler? I've looked in my copy of both your books hoping to see my answer but couldn't find it.

Thank so much.
-rmd

RE: How early can I use a mutex?

Posted by Richard on February 24, 2010

vSemaphoreCreateBinary() is implemented as:

{                                                                    \
    xSemaphore = xQueueCreate( ( unsigned portBASE_TYPE ) 1, 0 );    \
    if( xSemaphore != NULL )                                         \
    {                                                                \
        xSemaphoreGive( xSemaphore );                                \
    }                                                                \
}

so that would seem to provide the answer as far as xSemaphoreGive() is concerned (yes it is ok to call it). I think the same will be true for taking a semaphore too, provided a block time is never specified (as was previously mentioned).

Regards.