Open angainor opened 3 years ago
It also seems that the function body can be executed with and without a lock:
if (!m_mutex.try_lock())
if (m_free_stack.pop(b)) return b;
If m_free_stack.pop
fails, the execution continues, but the lock has not been acquired.
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?