On Mar 27, 2007, at 9:49 PM, Peter Dimov wrote:
There appears to be no need for a mutex in this prototype, unless I've missed something.
Even if the actual implementation uses no n2178::handle, the above sketch might still be useful as an illustration of the semantics and thread safety that I have in mind. The omission of joinable() and cancel_requested() is intentional, the omission of the rest of the members is for brevity, although hardware_concurrency would probably be better off as a free function.
Thanks for the code. Correct me if I'm wrong, but this code keeps state around after join and detach, and so might be problematic in the vector<thread> use case shown earlier (where potentially many threads can sit idle waiting to be recycled). Indeed, this implementation appears to simply wrap const semantics in a non-const handle. The "mixed thread safe" semantics I find interesting and a little worrisome. Having some functionality thread safe and some not could be seen as confusing. Looking again at the daemon spawner example: std::thread launch; ... vector<function<void()>> queue; while (!queue.empty()) { launch = std::thread(queue.back()); queue.pop_back(); register(launch.get_id()); if (something) break; launch.detach(); } // work with undetached launch thread here Except now "launch" is a global which other threads can access. Where is it safe to race against this code? A thread-safe detach() appears to have bought us little here since one would have to race against the thread-unsafe move assign. And the thread-safe detach() didn't come for free, we had to promise not to get rid of resources in the vector<thread> use case. Now we've got vector<thread> performance (good), but to do so we've partially compromised mulit-parent simultaneous access (bad), and we're potentially keeping resources around much longer than wanted (bad). Your suggestion is a compromise between the two designs (sole vs shared ownership), but I'm not sure it is a good compromise. I know we've got use cases which cry out for multi-parent access (thread pool is likely to be one). But by far the most common use cases appear to not need multi-parent access (http://www.boost.org/doc/html/threads/rationale.html#threads.rationale.non-c... ). And thread pool (and other shared-ownership use cases) can be layered onto the sole-ownership std::thread without compromise. -Howard