Le 25/10/12 10:42, Andrzej Krzemienski a écrit :
2012/10/25 Olaf van der Spek <ml@vdspek.org>
2012/10/25 Olaf van der Spek <ml@vdspek.org>
On Thu, Oct 25, 2012 at 9:56 AM, Andrzej Krzemienski < akrzemi1@gmail.com> wrote:
According to my (limited) understanding of the standard: no. Because, as per requirement in Sect 30.6.8 paragraph 5, the "launched" thread completion must synchronize with (happen before) the last function that releases the shared state.
If the launched thread finishes before the release, the thread cannot perform this release. But why? What's the rationale for this requirement? Is it the same rationale as the thread destructor of a non-detached
On Thu, Oct 25, 2012 at 10:11 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote: thread terminating (for safety)?
Basically, as with the thread's destructor: you have to do something: join, detach, signal run-time error. Your preference is clearly to detach. I could only found this document: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2802.html That gives some rationale against the detachment.
My guess is that termination was a good choice for a low-level primitive, and join was a good candidate for a higher-level primitive like async. async (owing to the joining destructor) gives you the ability to think in C-style scoped manner. Or in RAII way. You exit the scope, you are done with the resource (thread in this case). Yeah, I think you have explained a good reason to join. One may not like this async behaviour. One may write one's own multi-threading library using low-level threads. I guess it was the idea of the Kona compromise. Would you like to create a ticket to track this issue?
Thanks a lot Vicente