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/