Queues - thread safe? Mutual exclusion?

leesp wrote on Tuesday, August 28, 2018:

Hi,
Can someone explain to me in a simple manner, what does it mean by “FreeRTOS message queue are thread safe”? And how to use message queue for mutual exclusion to shared resources?
I know that message queue can be used by Task1, or ISR to send information to Task2, signalling Task2 that an event has happened. But use in thread safe, mutual exclusion, I am not sure
Thank you

rtel wrote on Tuesday, August 28, 2018:

Can someone explain to me in a simple manner, what does it mean by
“FreeRTOS message queue are thread safe”?

FreeRTOS allows your application to be organised as a set of independent
threads of execution (tasks) - if something is thread safe then it means
it can be used from more than one thread of execution as it is (without
the application writer needing to do anything special).

And how to use message queue
for mutual exclusion to shared resources?

While you could use a message queue for mutual exclusion of a resource,
it would be better to use a mutex. Rather than explain that here I
recommend reading about them in the texts already available to you on
the FreeRTOS.org website, and the relevant chapter in the FreeRTOS book
https://www.freertos.org/Documentation/RTOS_book.html

richard_damon wrote on Tuesday, August 28, 2018:

Queues are thread safe in that multiple tasks can try to concurrently write to or read from a given queue, and the queue will handle the syncronization so that each message gets put in as a unique message and each message gets sent to a single task.

(This is as opposed to Stream Buffers and Message Buffers which require that only a single task attempt write to or read from at any given time)

This means that Task1 and Task2 and ISR1 and ISR2 can all send messages using the same queue to Task3 and Task4, and neither the senders of the receivers need to worry about conflicts in access (just that the queue might be full).

leesp wrote on Wednesday, August 29, 2018:

This means that Task1 and Task2 and ISR1 and ISR2 can all send messages using the same queue to Task3 and Task4, and neither the senders of the receivers need to worry about conflicts in access (just that the queue might be full).

Q1. Correct me if I am wrong: so sending msg to a queue is thread safe because, for example, Task1 sends Msg1, Task2 sends Msg2. While interleaving may happen (which means while Task1 is sending, it might be interrupted or pre-empted by Task2, who is sending to the same queue), data integrity would be guaranteed (which means Msg1, Msg2 would not be corrupted). Because of this, queue is thread-safe
Q2. Reading from a queue would not post a concurrency or data corruption problem, right?

and each message gets sent to a single task.

Q3. How to ensure Task3, not Task4, gets Msg1?

rtel wrote on Wednesday, August 29, 2018:

This means that Task1 and Task2 and ISR1 and ISR2 can all send
messages using the same queue to Task3 and Task4, and neither the
senders of the receivers need to worry about conflicts in access
(just that the queue might be full).

Yes - note the ISRs need to use the ‘FromISR’ version of the queue APIs.

1. Correct me if I am wrong: so sending msg to a queue is thread
safe because, for example, Task1 sends Msg1, Task2 sends Msg2. While
interleaving may happen (which means while Task1 is sending, it
might be interrupted or pre-empted by Task2, who is sending to the
same queue), data integrity would be guaranteed (which means Msg1,
Msg2 would not be corrupted). Because of this, queue is thread-safe

Yes.

2. Reading from a queue would not post a concurrency or data
corruption problem, right?

Right.

and each message gets sent to a single task.
3. How to ensure Task3, not Task4, gets Msg1?

A single queue can have multiple readers and multiple writers. If more
than one task is blocked on a queue waiting to receive when a message
arrives then it is the highest priority task of the two that will
receive it - or if the tasks have the same priority - it is the task
that has been waiting the longest that will receive it.

This is in the book you know - please invest time in reading it so we
don’t have to repeat writing stuff here.

richarddamon wrote on Wednesday, August 29, 2018:

How to make sure the right Task gets a given message, basically you can’t. Normally having multiple readers on a queue is a way to implement a ‘Task Pool’ to handle concurent requests (likely running the same code, just with different stacks). If you care, you should have a dedicated queue for each task (so that would be used if after starting a request, it needs to get more information to complete the request).

leesp wrote on Wednesday, August 29, 2018:

Dear Richard,
I not only invested time in reading it, I also invested money to buy the books back in 2012 when they costed USD55! (And now they are FOC!)
It is just that there will always be questions after reading the book (any technical book in fact), and I really appreciate fellow forumers’s help to clear my doubts

rtel wrote on Wednesday, August 29, 2018:

Respect :o)