Re: [boost] Futures

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: 
> https://gist.github.com/sithhell/260796afcf11364eaf26

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 
problem?

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 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682052%28v=v
s.85%29.aspx.

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

That is a thin wrap of pthread_permit_XXX(). Try 
https://github.com/ned14/c11-permit-object/blob/master/pthread_permit.
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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/