When to create shared mutexes, semaphores, etc.

[henry_m]

Hi all,

I'm looking for the "recommended" way to initialise mutexes (or other things for task synchronisation for that matter) in MQX/MQX Lite.

Let's say I have a function which does some calculations and requires a mutex. This function may be used by some or all of my tasks. When is the best way to initialise the mutex?

Looking at some of the examples, a main task is normally started which creates the mutex and starts all other tasks afterwards. But I'm not sure whether this is actually the best way?

A "static" mutex would also work, but I don't see how that is possible with MQX/MQX-Lite?

Or should the mutex be initialised before the scheduler starts?

Thanks,

Henry

[soledad]

Hi Henry,

For MQXLite,  you can find examples in the following path:

CW MCU v10.x_install_path\MCU\CodeWarrior_Examples\Processor_Expert\MQXLite

For MQX, at the next path you can find sample codes that may help you. Freescale_MQX_4_0\mqx\examples

For example the mutex code is used to demonstrate how to use a mutex to synchronize two tasks. It creates a mutex and two tasks. Both tasks use STDOUT to print out messages. Each task will lock the mutex before printing and unlock it after printing to ensure that the outputs from tasks are not mixed together. In this code the main task first initializes the mutex with the following line:

_mutex_init(&print_mutex, &mutexattr)

Then the main task creates a print task with parameter sting1, and creates a second print task with parameter strings with the following line:

_task_create(0, PRINT_TASK, (uint_32)string1);

_task_create(0, PRINT_TASK, (uint_32)string2);

Then the main task blocks itself.

The two print tasks both use the STDOUT. If they used it in the same time, there would be conflicts, so a mutex is used to synchronize the two tasks.

Each print task will try to lock the mutex before printing the message; it will wait for the mutex as long as needed. Once the mutex is locked it prints the message and then unlocks the mutex so that the other task can lock it. This process is repeated indefinitely.

I hope this helps,

Regards

Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[henry_m]

Hi Sol,

thanks for your reply. Unfortunately it was not quite the answer I had hoped for. I looked of course at the examples, as I wrote in my original post and know how to create a mutex. My question was more about the best practice on when to create/initialise these, especially for mutexes which are used by all/most tasks (e.g. as in the example for logging or output).

But I suppose the way from the examples, of using one single task for initialisation is the recommended way? Although it seems a pity to not be able to use the task auto start feature but for the main/initialisation task. Especially for projects with MQX Lite and Processor Expert, where tasks are essentially configured graphically.

Focusing on MQX Lite and Processor Expert, I just looked at ProcessorExpert.c (in CW 10.5) and noticed that _mqxlite_init is already done in PE_low_level_init (and not later in _mqxlite() as I thought). So, would it be a good idea to do the initialisation in main() between PE_low_level_init() and PEX_RTOS_START()? Or is this a bad idea and one shouldn't use MQX(Lite) functions "outside" a task? Of course, one mustn't use blocking calls which rely on the scheduler, but would it be Ok for initialising mutexes, semaphores, etc.?

Henry