On 27/05/2019 19:17, Martin Erik Werner wrote:
In the C-user documentation, section 8.3.2. "Directives Allowed from an ISR", rtems_message_queue_{send,urgent} are marked as allowed, but not rtems_message_queue_broadcast.What is the reason for its omission there? Is it a "soft disallow" due to the time taken being variable and potentially long based on the amount of listeners (compared to normal send), or is it due to some other fundamental property that makes it a "definite disallow"?
This was an oversight. Technically, there is nothing that prevents its use in interrupt context. It is up to the application to make the trade off between the potentially large time it needs to do the broadcast and other constraints.
On the same subject, are non-blocking directives (e.g. rtems_semaphore_obtain + RTEMS_NO_WAIT) disallowed? Or is it only the blocking versions of these directives that are to be avoided?
A rtems_semaphore_obtain() for mutex-like variants is undefined behaviour if you call it in interrupt context since they need an owner thread.
A rtems_semaphore_obtain() for simple binary or counting semaphores with RTEMS_NO_WAIT technically works, however, what is the use case?
-- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
