What to do with rtems_semaphore_flush() on SMP?

[Joel Sherrill]

On Tue, Mar 22, 2016 at 8:56 AM, Sebastian Huber <
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.



> The rtems_semaphore_obtain/release() use fine grained locking via the the
> thread queue lock of the object. rtems_semaphore_flush() in contrast uses
> the Giant lock and disabled thread dispatching. It is possible to generate
> livelock conditions in case a thread constantly calls
> rtems_semaphore_obtain() and another thread constantly calls
> rtems_semaphore_flush() (needs at least two processors).
>
> One option would be to protect the complete _Thread_queue_Flush()
> operation with the thread queue lock. This would result in a very big
> critical section especially in case priority inheritance with OMIP support
> (will be implemented later this year) is involved. There are some difficult
> corner cases with thread deletion as well.
>
> I am inclined to disable rtems_semaphore_flush() on SMP configurations,
> e.g. if RTEMS_SMP and rtems_configuration_is_smp_enabled().
>
> --
> 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.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160322/fee633b0/attachment-0002.html>