From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-27 19:40:32
I'm coming full circle...
As soon as I start allowing multiple threads to access std::thread at
once, I need to keep a mutex around for the lifetime of the
std::thread, whether or not it is already joined or even detached:
pthread_t handle_; // 0 if detached
thread_local_data* tl_ // 0 if detached
mutex mut; // synchronize between parent and child threads
mutex another_mut; // synchronize with multi-parent access,
I can never get rid of another_mut, even after thread detach, even
t = std::thread();
I believe I'll even have to lock t.another_mut during the above move
assign, making move assign unacceptably slow.
This is the wrong class to allow multiple threads to touch at once.
Even if I load it with another_mut and bring move assignment to a
crawl, simultaneous access to join() and detach() is still a race.
To accomplish that insert we just had to lock/unlock 100 mutexes. I
actually did this with std::string many years ago, and I *still* have
the bruises from my customers! Either that or we go with detach()
being a no-op as Peter suggests and we keep the thread state around
forever. And then we still just did 100 atomic operations to get that
> I think that all operations on std::thread should be safe to execute
> concurrently, and that they should have defined functionality in all
> which should probably be a no-op.
Sorry, I just do not believe this is a good idea. It completely
destroys vector<thread> performance for what is at best a corner use
case and can be handled with layered-on classes or otherwise applied
external synchronization if desired. The whole beauty of the sole-
ownership model is how light and agile it is to manipulate.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk