Mutex and IRQ

Kernel
1

The macro/function that take/give a mutex are executed with ISR disabled?

and the take macro on a mutex, if the mutex is not available, put the thread in a blocked state ?
Thanks,
Piero

2

Not totally sure on your question, but the functions to take a semaphore/mutex do have short periods inside them where they disable interrupts when accessing some critical information. If the function is given a non-zero wait time, then if the semaphore/mutex isn’t available the calling task will block until it is, or the time limit expires.

You generally should NOT call these function with a non-zero block time with interrupts disabled (as in a critical section), as switching tasks with interrupts disabled isn’t supported by all ports, and when it is, it tends to result in the interrupts be enabled while the task is blocked.

3

Thanks for your reply.
I’ll try to be more clear: are RTOS mutex implemented so that they guarantee mutual excusion in every condition?
Here is an example to explain my question:
a (theoretical) implementation of a take function could be:
take(s):{
if (s == 0)

else s = 0
}
Suppose now that 2 threads, P1 and P2, must access a resource in mutual exclusion, so they access the resource via the take primitive.
Suppose that s (in the above code) is equal to 1, and the two threads are both executing the if statement (for instance because P1 is executing the if, and it is preempted by P2 that is executing also the if). in this case, both find s!=0, so both have access to the resources.
My question is if free RTOS correctly manages this situation.
Thanks again,
Piero

4

You might have a look at the sources. Probably interrupts are disabled and hence the scheduler is off during the internal bookkeeping of the mutex to ensure exclusive execution of the related code.

5

the correct version of the code is:
take(s):{
if (s == 0)
// block the thread
else s = 0
}

6

In FreeRTOS, the xSemaphoreTake (and xSemaphoreTakeRecursive for recursive mutexes) has in it a critical section so that it ‘works’. It guarantees that only the specified number (1 unless it is a counting semaphore) of tasks could have taken the semaphore until it is given back again.