https://svn.boost.org/trac10/ticket/13442 <p> In our setup, we have several high priority threads that occasionally need to allocate memory using <code>synchronized_pool_resource::allocate</code>. Such memory is later released by a lower priority thread using <code>synchronized_pool_resource::deallocate</code>. </p> <p> It might sometimes happen that several <code>allocate</code> calls happen simultaneously with <code>deallocate</code>. Because of the spinlock implementation used by dlmalloc, the high priority threads are in a busy loop trying to acquire the lock, but the kernel might have no resources left to awake the "cleaner" thread that is currently holding the lock. </p> <p> Attached is a minimum example that Linux <code>SCHED_FIFO</code> scheduler. Running the program, on my system I can see: </p> <blockquote> <p> 1) The program prints 'failed' several times, meaning that some calls to <code>allocate</code> blocked for more than a second. </p> </blockquote> <blockquote> <p> 2) The total execution time is approximately 120 times slower than a version that does not use any thread priority. </p> </blockquote> <p> Inspecting the program with <code>perf</code> one can see that most of the time is spent inside <code>boost_cont_sync_lock</code>, in particular in <code>sched_yield</code>. </p> <p> A possible solution could be to switch to a pure pthread implementation by defining <code>USE_SPIN_LOCKS=0</code> before including <code>dlmalloc_2_8_6.c</code> </p> <p> System: <code>Linux SPC-LT48 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux</code> </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/13442 Trac 1.4.3 enniobarbaro@… Wed, 07 Feb 2018 09:42:03 GMT https://svn.boost.org/trac10/ticket/13442 https://svn.boost.org/trac10/ticket/13442 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">main.cpp</span> </li> </ul> Ticket Ion Gaztañaga Fri, 09 Feb 2018 17:17:32 GMT