2

Particularly i want to use them with boost::asio::thread pool. It seems to work for the first sight, but i have doubts.

For clarification: I know that std::thread is based on boost::thread, but asio::thread_pool is using it's own thread implementation for some reason that isn't obvious to me.

I use std::future and std::promise for inter-thread signaling of interruption and completion state of user code.

Nishant Singh
  • 4,177
  • 1
  • 17
  • 17
Elohim Meth
  • 1,777
  • 9
  • 13
  • A thread pool will still run in a separate thread, so it's really no different from a `std::thread` in that sense. Depending on your use case `std::packaged_task` mi ght be an even better fit for you. – super Dec 19 '18 at 07:17
  • AFAK, std::promise and std::future use mutex and condition variable on Windows. So, i think it is safe to be used in non std::thread. – Wei Guo Dec 19 '18 at 07:41

3 Answers3

2

All the "thread" implementations you mention in your questions are models of the same thing: the target OS's threads.

As long as the code that fills the std::promise can eventually get there, you can wait on the std::future. It doesn't matter to those two, how the OS threads they run on were started.

Caleth
  • 52,200
  • 2
  • 44
  • 75
  • With one big caveat: there is a difference between e.g. _createthreadex and CreateThread on Windows. See e.g. [this answer](https://stackoverflow.com/a/331567/256138). It might influence how the C and/or C++ runtime works for those threads. – rubenvb Dec 19 '18 at 10:21
  • @rubenvb that falls under "don't do 'implementation defined' incorrectly" – Caleth Dec 19 '18 at 10:25
0

std::thread is heavily based on boost's version: so it will work 100%.

In general, it ought to work with all other versions of threads. future and promise work due to memory model and the actual implementation of the thread is not important for them.

The only issue I can imagine is that promise is not passed into the thread correctly but that would be just some coding bug and it would cause failure every time.

ALX23z
  • 4,456
  • 1
  • 11
  • 18
0

I don't know if we can answer this definitively on our own so let's see the experts who worked with Boost and standard library have to say.

Anthony Williams who had been the primary developer and maintainer of the Boost Thread Library says this in his book "C++ Concurrency in Action" (one of the books in the C++ Definitive Books list) says this:

The Boost Thread Library provides an API that’s based on the C++11 Standard Thread Library proposals and is portable to many platforms. Most of the examples from the book can be modified to work with the Boost Thread Library by judicious replacement of std:: with boost:: and use of the appropriate #include directives. There are a few facilities that are either not supported (such as std::async) or have different names (such as boost::unique_future) in the Boost Thread Library.

The new C++ Thread Library is heavily based on the prior experience accumulated through the use of the C++ class libraries mentioned previously. In particular, the Boost Thread Library has been used as the primary model on which the new library is based, with many of the classes sharing their names and structure with the corresponding ones from Boost. As the new standard has evolved, this has been a two-way flow, and the Boost Thread Library has itself changed to match the C++ Standard in many respects, so users transitioning from Boost should find themselves very much at home.

P.W
  • 26,289
  • 6
  • 39
  • 76