On 22/03/16 15:23, Joel Sherrill wrote:
On Tue, Mar 22, 2016 at 8:56 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.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
