You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems to me that pool::allocate can return without unlocking an internally locked mutex. There are a number of return statements on the way before m_mutex.unlock();. It also seems there is quite a number of if (m_free_stack.pop(b)) return b; calls. Can this be simplified?
auto allocate()
{
block_type b;
if (m_free_stack.pop(b)) return b;
if (!m_mutex.try_lock())
if (m_free_stack.pop(b)) return b;
if (m_free_stack.pop(b)) return b;
for (auto& kvp : m_segments) kvp.first->collect(m_free_stack);
if (m_free_stack.pop(b)) return b;
unsigned int counter = 0;
while (!m_free_stack.pop(b))
{
// add segments every 2nd iteration
if (++counter % 2 == 0) add_segment();
}
m_mutex.unlock();
return b;
}
The text was updated successfully, but these errors were encountered:
I pushed a fix: added a while loop to lock for sure. Now it should be thread safe. About simplification: we could potentially remove some of the pops, yes
It seems to me that
pool::allocate
can return without unlocking an internally locked mutex. There are a number ofreturn
statements on the way beforem_mutex.unlock();
. It also seems there is quite a number ofif (m_free_stack.pop(b)) return b;
calls. Can this be simplified?The text was updated successfully, but these errors were encountered: