Wrap pthread objects

[rgacogne]

Short description

This PR wraps the remaining pthread_* objects in our code base:

• pthread_mutex_t -> std::mutex (always correctly initialized, can't be copied, properly destroyed via RAII) ;
• pthread_rwlock_t -> ReadWriteLock (light wrapper, always correctly initialized, can't be copied, properly destroyed via RAII) ;
• pthread_create -> std::thread (no need of an awkward wrapper to pass the parameters, easier to join or detach).

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[pieterlexis]

Related: #6993

[rgacogne]

I missed a few spots, fixing that now.

[rgacogne]

Rebased to fix a conflict with #9069.

[rgacogne]

I missed a few spots, fixing that now.

Done, ready for review!

[omoerbeek]

wrt lock.hh: Is g_singleThreaded still useful? AFAIK it is never set.
Is the class Lock still useful?

[rgacogne]

wrt lock.hh: Is g_singleThreaded still useful? AFAIK it is never set.

Yeah, I was looking at the same thing. I think it should go, the idea was nice but we never used it and IMHO this is an optimization best left to the implementation.

Is the class Lock still useful?

It's gone :)

[rgacogne]

I just removed g_singleThreaded.

[omoerbeek]

I looked at making the constructors taking a pthread_rwlock_t * private to avoid re-introducing lock objects using pthread rw locks. That does compie, so if you agree I can push the diff to this branch.

[rgacogne]

I looked at making the constructors taking a pthread_rwlock_t * private to avoid re-introducing lock objects using pthread rw locks. That does compie, so if you agree I can push the diff to this branch.

Nice idea, I like it!

[omoerbeek]

Love how this makes all kinds of errors less likely to occur.