What to do with rtems_semaphore_flush() on SMP?

[Sebastian Huber]

On 22/03/16 15:23, Joel Sherrill wrote:
>
>
> On Tue, Mar 22, 2016 at 8:56 AM, Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     Hello,
>
>     I am currently busy with eliminating the Giant lock for SMP. I
>     came across a problem with rtems_semaphore_flush() and
>     _Thread_queue_Flush().
>
>     In general the rtems_semaphore_flush() is difficult to use
>     correctly. For example it could be used for condition
>     synchronization, however, it must be combined with the no-preempt
>     mode otherwise is subject to the lost wakeup problem. The
>     no-preempt mode is not available on SMP configurations. See also
>     rtems_bdbuf_anonymous_wait()
>
>     https://git.rtems.org/rtems/tree/cpukit/libblock/src/bdbuf.c#n1080
>
>     What is a valid use case for rtems_semaphore_flush() on SMP
>     configurations?
>
>
> It has been used in the past for mode/state transition 
> synchronizations. But
> it was initially added because people moving over from VxWorks used it
> as a condition synchronization. Does VxWorks disable it in SMP?
>
> You mention inheritance problems but that only applies to mutexes not
> counting semaphores.
>
> Also we have other similar operations like barrier release, MQ 
> broadcast, and MQ flush.

Yes, the barrier release is a problem. So, we need some sort of 
_Thread_queue_Flush() completely protected by the thread queue lock. Its 
not as bad as with priority inheritance mutexes.

The MQ broadcast and flush are not a problem since they work slightly 
different. However, if you consume a message faster than the 
broadcasting thread, then you receive the same message again and again 
(maybe not 100% sure).

-- 
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.