<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 8:56 AM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I am currently busy with eliminating the Giant lock for SMP. I came across a problem with rtems_semaphore_flush() and _Thread_queue_Flush().<br>
<br>
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()<br>
<br>
<a href="https://git.rtems.org/rtems/tree/cpukit/libblock/src/bdbuf.c#n1080" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/cpukit/libblock/src/bdbuf.c#n1080</a><br>
<br>
What is a valid use case for rtems_semaphore_flush() on SMP configurations?<br>
<br></blockquote><div><br></div><div>It has been used in the past for mode/state transition synchronizations. But</div><div>it was initially added because people moving over from VxWorks used it</div><div>as a condition synchronization. Does VxWorks disable it in SMP?</div><div><br></div><div>You mention inheritance problems but that only applies to mutexes not </div><div>counting semaphores. </div><div><br></div><div>Also we have other similar operations like barrier release, MQ broadcast, and MQ flush.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
<br>
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.<br>
<br>
I am inclined to disable rtems_semaphore_flush() on SMP configurations, e.g. if RTEMS_SMP and rtems_configuration_is_smp_enabled().<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div><br></div></div>