Blocking Queues in F'

[Gonta01]

This issue is related to FreeRTOS eventGroups, semaphores in F'
@LeStarch suggested to use Os::Mutex as a substitution for eventGroups, semaphores but I used messageQueue instead.
Here is example:

Inside active component is used send_data():

void send_data() {
if (startSend()) {
waitSendEnd();
}
}

startSend initiates hardware data sending;

waitSendEnd waits until data sending ends.

void waitSendEnd {
queue.receive(); // waits in blocking mode since there is no way in OSAL queue to set timeout whereas FreeRTOS gives such opportunity
}

SendEndHandler {
queue.send();
}

Here is problem: if sendEndHandler didn't work (interrupt didn't finished for some hardware reason), the system will collapse because of invocation overflow (rateGroup will invocate run handler but the task is blocked because of waitSendEnd())

Similarly for receive_data:
void receive_data() {
if (startReception()) {
waitReceptionEnd();
}
}

If nothing will be received the whole system will be collapsed because task is suspended and wait for reception of some data.

The questions are:

1. Why doesn't F' OSAL give ability to use timeout for queue receive?
2. Does approach above is compatible with F' ideology? What are alternatives?
3. Could Os::Mutex be used here to resolve this as it was suggested in another issue. Originally instead of queue was used eventGroups.

[LeStarch]

1. F´ queues where built to be the basis of an event loop of the form:

while (message != EXIT) {
    m = q.receive
    process(m)
}
// End of FSW

For this use-case no timeout is needed as it will just try to receive again.

2. @timcanham can you answer this?
3. Theoretically you could lock a mutex while sending the data. This would ensure that the other receive_data handler is in one of three states:
4. Not started
5. Data sent
6. Data sent, but erred
   You could set a state variable and track in receive_data

[timcanham]

2. I don't think timeouts are against F Prime ideology, but the primary use-case is within the message loop as @LeStarch says. I could see it as an optional parameter for the receive() call, where F Prime components could use the block-forever option (usually timeout of zero). If we have unknown timeouts, it is hazardous to stall the message handling loop as @Gonta01 has stated. There are two other options as I see it. Send the message, and have the destination do a callback through a port. The timeout can be done by: 1) A scheduler call if the scale is on the order of seconds. 2) A timer callback. Both of these would free up the message queue.