An improper locking bug on the lock NewThread->StartMutex about os HOT 4 OPEN

Thanks Ryan! Technically you're right, things would be aesthetically balanced if we had a pthread_mutex_unlock(&(NewThread->StartMutex)) in the !KSUCCESS() case. In practice it doesn't end up mattering because NewThread is being destroyed in the !KSUCCESS() case, having failed to start the new thread.

I'm tempted to leave things as-is.

from os.

@evangreen Hi, thank you for your reply and confirm this!

There is a similar case, the Thread->StartMutex is not released before the thread goes die. Would it better to release the lock before?

from os.

Hm. It's a similar story there. The StartMutex acts like a barrier, ensuring that ClpThreadStart() doesn't let the thread run its main routine until pthread_create() has finished initializing the thread members. I suppose the StartMutex could be replaced with a pthread_cond_t, but the mutex is a little lighter.

from os.

@evangreen OK, Thank you. Feel free to close this issue if they would be fixed.

from os.