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