ThreadSanitizer reports destruction of locked mutex in threadpool_free. about concord

[nephatrine]

It's not just a consequence of optimization, the lock is literally right before the destroy call in the code. No amount of sleeping will change that.

        /* Because we allocate pool->threads after initializing the
           mutex and condition variable, we're sure they're
           initialized. Let's lock the mutex just in case. */
        pthread_mutex_lock(&(pool->lock));
        pthread_mutex_destroy(&(pool->lock));

https://linux.die.net/man/3/pthread_mutex_destroy
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_destroy.html

Attempting to destroy a locked mutex results in undefined behavior.

I'd imagine that this is actually "harmless" in practice, but for what reason is it being locked before being destroyed? If we need that lock there, then just inserting an unlock immediately afterwards would suffice to comply with the POSIX standard. The only concern I see is if you think something else could lock it between the unlock and the destroy, but if you've got other threads still trying to use the mutex at that point then you've got bigger issues.

[lcsmuller]

I suspect that this is not an actual bug, but a consequence of pthread's optimization, see: https://stackoverflow.com/a/68514238

I had also come across a similar error when running my application under valgrind, but after some research I came to the conclusion that it's a harmless "leak". You can probably circumvent it by having your process sleep for a little while before termination. If you believe that your issue is unrelated to this, feel free to re-open this issue.

[lcsmuller]

I'll take a better look at this once I get home, I may have mixed up your issue with something else I was having. My bad for just assuming.

It's not just a consequence of optimization, the lock is literally right before the destroy call in the code. No amount of sleeping will change that.

In the meantime, can you confirm that changing the ordering fixes the issue? If so, could you please open a PR fixing it?

[lcsmuller]

Just to give a bit of a context, the issue arises from how this third-party threadpool lib manages its clean up. We can either look for an alternative (C99 compliant) threadpool implementation, write our own, or fix this one (and send a fix PR to the original's out of courtesy).