rtems_message_queue_broadcast() may, under certain circumstances, copy
the message to tasks which were not waiting on the message queue when
the broadcast started, and may copy the message multiple times to the
same task.
This behaviour is, based on discussion in #4804, something that might
be
unlikely to change.
Expose the note regarding this behaviour that already existed in
the requirement spec in the main documentation as well. Removing the
"Currently" wording.
Update #4804.
---
modules/rtems-docs | 2 +-
spec/rtems/message/if/broadcast.yml | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/modules/rtems-docs b/modules/rtems-docs
index cb375249..e4e70bc5 160000
--- a/modules/rtems-docs
+++ b/modules/rtems-docs
@@ -1 +1 @@
-Subproject commit cb375249c59bf7542c4115668dcfbcd7d50d41de
+Subproject commit e4e70bc54c581d01a988fde075c711f3c6acc9e5
diff --git a/spec/rtems/message/if/broadcast.yml
b/spec/rtems/message/if/broadcast.yml
index 0a2f77b3..61ba4106 100644
--- a/spec/rtems/message/if/broadcast.yml
+++ b/spec/rtems/message/if/broadcast.yml
@@ -44,6 +44,14 @@ notes: |
The execution time of this directive is directly related to the
number of
tasks waiting on the message queue, although it is more efficient
than the
equivalent number of invocations of ${send:/name}.
+
+ ${../if/broadcast:/name} unblocks ${../glossary/receiver:/plural} in
a
+ non-atomic way. Meaning, it will not only
${../glossary/unblock:/term} those
+ ${../glossary/receiver:/plural} it finds waiting at the queue when
+ ${../if/broadcast:/name} is invoked but also any new
+ ${../glossary/receiver:/plural} which start waiting for messages
after
+ ${../if/broadcast:/name} is invoked and before it returns. This may
lead to
+ infinite unblocking loops.
params:
- description: |
is the queue identifier.
--
2.30.2
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
