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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
