并发入门C++

何谓并发

单个系统里同时执行多个独立的活动。

并发的途径

多进程并发

使用并发的第一种方法，是将应用程序分为多个独立的进程，它们在同一时刻运行，就像同时进行网页浏览和文字处理一样。如图1.3所示，独立的进程可以通过进程间常规的通信渠道传递讯息(信号、套接字、文件、管道等等)。不过，这种进程之间的通信通常不是设置复杂，就是速度慢，这是因为操作系统会在进程间提供了一定的保护措施，以避免一个进程去修改另一个进程的数据。还有一个缺点是，运行多个进程所需的固定开销：需要时间启动进程，操作系统需要内部资源来管理进程，等等。

当然，以上的机制也不是一无是处：操作系统在进程间提供附加的保护操作和更高级别的通信机制，意味着可以更容易编写安全的并发代码。实际上，在类似于Erlang的编程环境中，将进程作为并发的基本构造块。

使用多进程实现并发还有一个额外的优势——可以使用远程连接(可能需要联网)的方式，在不同的机器上运行独立的进程。虽然，这增加了通信成本，但在设计精良的系统上，这可能是一个提高并行可用行和性能的低成本方式。

多线程并发

并发的另一个途径，在单个进程中运行多个线程。线程很像轻量级的进程：每个线程相互独立运行，且线程可以在不同的指令序列中运行。但是，进程中的所有线程都共享地址空间，并且所有线程访问到大部分数据———全局变量仍然是全局的，指针、对象的引用或数据可以在线程之间传递。虽然，进程之间通常共享内存，但是这种共享通常是难以建立和管理的。因为，同一数据的内存地址在不同的进程中是不相同。图1.4展示了一个进程中的两个线程通过共享内存进行通信。

为什么使用并发？

关注点分离（SOC） 性能

什么时候不使用并发

收益比不上成本： 除非潜在的性能增益足够大或关注点分离足够清晰，能抵消所需的额外的开发时间以及维护多线程代码相关的额外成本，否则别用并发。

并发编程一定会使我们的程序运行的更快吗？

答案是并不是，并发编程只有在一定的请求量或者计算量的时候才会显示出优势；

为什么有的时候多线程反而会变慢呢？

我们知道os（操作系统）执行并发操作是采用的时间片轮转算法，简单的说就是线程1先执行10ms 然后线程B在执行10ms 然后线程A又执行了10ms 线程A执行完毕 线程B又开始执行到结束

我们可以发现这种执行的机制，会导致cpu一会执行A线程 一会执行B线程，这就导出了一个第一个导致多线程慢的因素：线程的上下文切花需要时间
补充：Java创建多线程需要OS的干预，OS需要从用户态切换到核心态 这个过程很耗费时间

那么简单的理解就是：如果多线程执行的速度快于单线程执行的速度，那么我们可以理解为多线程一定会在执行前做一些准备，而单线程不需要，所以当任务数或者工作量并不大的时候单线程就会很有优势；但是当任务数上来后多线程的优势就体现出来了；
这里我们有个可以继续深入研究的点：即具体什么时候，什么情况下单线程执行优于多线程

那么如何提高并发编程的性能呢？

我们知道并发性能的瓶颈就是频繁的上下文切换，那么我们就可以通过减少上下文的切换来提高性能。

减少上下文切换的方法：

    采用无锁并发编程：多线程竞争锁的时候就会引起上下文的切换，所以处理数据的时候应该避免加锁，可以把数据分段，每个线程来处理一段的数据，

    CAS算法： Java的Atomic包使用CAS算法来更新数据，不需要加锁

    尽量合理的配置线程即使用最少的线程：例如我们处理一个任务10个线程100ms搞定，那么你开100000个线程来处理，光上下文切换的时间都要超过100ms

    使用协程：在单线程里实现任务的调度，并在单线程里维持多个任务的切换

为什么并发编程会使我们的程序变得更快呢？

首先对于单线程来说，程序是一行一行的执行的，所以假设在120行-180行之间的程序含有数据库操作需要等待很长时间，那么180行以后的代码都必须等到180行的代码执行完才能继续执行，而并发编程其实就是异步化，也就是主线程在执行到120行的时候，120-180行的代码交给另一个线程去执行，主线程可以继续向下执行，所以两件事是并行的，所以程序的响应时间就会变快.

#include <iostream>
#include <thread>

using namespace std;

void hello()
{
    cout << "Hello Comcurrent World!" << endl;
}

int main()
{
    thread t(hello);
    t.join();

}

Hello Comcurrent World!
按 <RETURN> 来关闭窗口...