What to do with rtems_semaphore_flush() on SMP?

[Sebastian Huber]

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?

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.