msg broadcast or non-block directives from interrupt context?
Sebastian Huber
sebastian.huber at embedded-brains.de
Tue May 28 05:48:21 UTC 2019
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.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the users
mailing list