boost's thread or std's thread?

[JiiPee]

I am thinking with one or my friends whether we should use boost's
thread or std's thread? Are they very similar? I have never used boost's
thread-system. Which one you would use? thanks

[Paavo Helde]

They are pretty similar, boost's implementation just served as the test
bench for standardization. Some boost features like thread cancellation
have been left out from std::thread, this is arguably a good thing.

One should always prefer standard tools whenever possible so one should
use std::thread nowadays.

[JiiPee]

thanks, that is what I was thinking as well.

But, as my friend mentiones, boost seems to be able to do concurrent
programming without threads. Is this gonna be significantly better
solution (so no need to start threads):


The Proactor Design Pattern: Concurrency Without Threads
<http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html>

http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html

I have no clue what this is, but just looking for a direction.

[JiiPee]

>
> http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html
>
>
> I have no clue what this is, but just looking for a direction.

Seems to say its more efficient. Is this true:

Performance and scalability.

Implementation strategies such as thread-per-connection (which a
synchronous-only approach would require) can degrade system
performance, due to increased context switching, synchronisation and
data movement among CPUs. With asynchronous operations it is
possible to avoid the cost of context switching by minimising the
number of operating system threads — typically a limited resource —
and only activating the logical threads of control that have events
to process.

[Ian Collins]

I had a similar discussion with a group of colleagues yesterday and we
all agreed asio is OK for situations where you need to manage multiple
concurrent connections and threads are better when the number is small
(often one!). Using asynchronous I/O is seldom simple!

--
Ian

[Paavo Helde]

This is about async I/O, which is very relevant if your program is
I/O-bound. If it is CPU-bound, then the things get different and real
multi-threading might provide an answer.

The optimal solution depends a lot on the concrete task and the
properties of the available hardware. For example, nowadays some tasks
are best accomplished by GPU-s (which are not directly related to
neither async I/O nor to what is commonly called multithreading).

A general advice: if you have no experience in the area, there is not
much point in striving to the most effective solution the first time,
you will not achieve that anyway. Instead, you should try to develop a
decent, correctly working program, preferably multiple programs using
different approaches if possible, for comparison. The time to focus on
top performance will come maybe after some 5 years when you have
gathered enough experience.

[JiiPee]

On 17/05/2017 20:46, Paavo Helde wrote:
> A general advice: if you have no experience in the area, there is not
> much point in striving to the most effective solution the first time,
> you will not achieve that anyway. Instead, you should try to develop a
> decent, correctly working program, preferably multiple programs using
> different approaches if possible, for comparison. The time to focus on
> top performance will come maybe after some 5 years when you have
> gathered enough experience.

Thanks. Yes I would agree. The performance is not necessary hugely
better unless statistics/tests proves about it.

[Marcel Mueller]

If in doubt prefer the std version unless you have good reasons not to
do so.


Marcel

[Chris M. Thomasson]

Use the standard.