Boost logo

Boost :

Subject: Re: [boost] Futures
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-14 07:20:43

On 13 Jan 2015 at 16:52, Thomas Heller wrote:

> Non-allocating futures (and by implication non reference counted shared
> states) have a major problem. I am basing my observation on your
> proposal of basic_future and basic_promise (with my assumption to have
> the nomenclature as in the standard). The problem is dangling pointers:

I think you used v2 of the test code? I didn't bother with the move
constructor implementation as that had been proved in v1. The point
of v2 was to test the functional composure method of building up
future and promise type implementations - basically, would the
compiler optimiser cope? As you may have seen in the comments in v2,
the answer was "not bad, though with bugs".

> I can see that the problem 1 could get fixed easily by updating the

> pointer the promise is pointing to ... but what about the second

In v1, and I would assume any final implementation, both promise<T>
and future<T> keep inline storage for a T. In problem 2, promise only
takes a copy of the set value if and only if not future has never
been retrieved, else promise always sends set values straight to the
linked future.

In problem 2, if the thread finished before you get the value from
the future, it is not a problem because the promise sent to the
thread sent the set value to its linked future, and so the future now
holds the set value. The promise, after a future is taken from it, is
no more than a dumb pointer to the future.

> >> A portable, universal kernel wait object is
> >> not really necessary for that.
> >
> > I think a portable, universal C API kernel wait object is very
> > necessary if C++ is to style itself as a first tier systems
> > programming language.
> >
> > We keep trivialising C compatibility, and we should not.
> No one is trivialising C compatibility. You can call any C code from C++.

I think I was clear that I meant the other way round. C code needing
to compose waiting on C++ code to do something with other operations
is a major pain. Ask anyone working in the Python C runtime and
trying to work with C++ code.

> > That said, its design is highly limited to doing what it does because
> > it has to make hard coded conservative assumptions about its
> > surrounding environment. It can't support coroutines for example, and
> > the fairness implementation does make it quite slow compared to a CAS
> > lock because it can't know if fairness is important or not, so it
> > must assume it is. Still, this is a price you need to pay if you want
> > a C API which cannot take template specialisations.
> So it is limited but generic? That doesn't make sense.

All C API threading primitives are the same. Right now, for example,
the Linux glibc pthread mutex has a spin count set for CPUs which
existed ten years ago, and is too short for modern CPUs. It is
unfortunately non-adjustable from the outside, and produces
suboptimal performance on modern CPUs.

Limited and generic, as you said.

> >> This is an implementation detail of a specific future
> >> island, IMHO. Aside from that, i don't want to limit myself to POSIX.
> >
> > My POSIX permit object also works perfectly on Windows using the
> > Windows condition variable API. And on Boost.Thread incidentally, I
> > patch in the Boost.Thread condition_variable implementation. That
> > gains me the thread cancellation emulation support in Boost.Thread
> > and makes the boost::permit<> class fairly trivial to implement.
> Please decide yourself what you want to call it ... is it POSIX now or
> platform indepedent?

It follows the POSIX pthreads API and naming conventions, but it
compiles and works on the platforms I indicated.

Windows also provides POSIX pthreads primitives, though not following
the API and naming conventions. See

> Is it C or C++? boost::permit<> looks pretty C++-ish to me.

That is a thin wrap of pthread_permit_XXX(). Try
h for a reasonably up to date version. I have a version here which
does the lazy condvar allocation, but it isn't as tested as I'd like.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at