Diffstat (limited to 'c/src/exec/score/src/coremsgflushsupp.c')
1 files changed, 27 insertions, 0 deletions
diff --git a/c/src/exec/score/src/coremsgflushsupp.c b/c/src/exec/score/src/coremsgflushsupp.c
index f221be000e..4bfd8f358b 100644
@@ -57,6 +57,33 @@ unsigned32 _CORE_message_queue_Flush_support(
+ * Currently, RTEMS supports no API that has both flush and blocking
+ * sends. Thus, this routine assumes that there are no senders
+ * blocked waiting to send messages. In the event, that an API is
+ * added that can flush a message queue when threads are blocked
+ * waiting to send, there are two basic behaviors envisioned:
+ * (1) The thread queue of pending senders is a logical extension
+ * of the pending message queue. In this case, it should be
+ * flushed using the _Thread_queue_Flush() service with a status
+ * such as CORE_MESSAGE_QUEUE_SENDER_FLUSHED (which currently does
+ * not exist). This can be implemented without changing the "big-O"
+ * of the message flushing part of the routine.
+ * (2) Only the actual messages queued should be purged. In this case,
+ * the blocked sender threads must be allowed to send their messages.
+ * In this case, the implementation will be forced to individually
+ * dequeue the senders and queue their messages. This will force
+ * this routine to have "big O(n)" where n is the number of blocked
+ * senders. If there are more messages pending than senders blocked,
+ * then the existing flush code can be used to dispose of the remaining
+ * pending messages.
+ * For now, though, we are very happy to have a small routine with
+ * fixed execution time that only deals with pending messages.
_ISR_Disable( level );
inactive_first = the_message_queue->Inactive_messages.first;
message_queue_first = the_message_queue->Pending_messages.first;