Le 25/10/12 10:22, Olaf van der Spek a écrit :
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:
The third situation below shows a non blocking ~future. But such execution is *disallowed *by the standard because the completion of launched thread would not synchronize with the last release of the shared state. The big question is: why?
Can't the destructor detach from the shared state and let the state be cleaned up by the launched thread?
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)?
Oh I guess I start to understand the standard rationale. Vicente