Re: [boost] [thread] terminating destructor

Subject: Re: [boost] [thread] terminating destructor
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-10-25 04:42:50

2012/10/25 Olaf van der Spek <ml_at_[hidden]>

> On Thu, Oct 25, 2012 at 10:11 AM, Andrzej Krzemienski
> <akrzemi1_at_[hidden]> wrote:
> > 2012/10/25 Olaf van der Spek <ml_at_[hidden]>
> >
> >> On Thu, Oct 25, 2012 at 9:56 AM, Andrzej Krzemienski <
> akrzemi1_at_[hidden]>
> >> 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
> 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).

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.

Regards,
&rzej