再也不用std::thread编写多线程了

int sys = 1;

int doAsyncWork()
{
    sys ++;
    
    std::cout<<"sys: "<<sys<<std::endl;

    return sys;
}


int main()
{
    //方式一：基于线程
    std::thread t(doAsyncWork);
    t.join();
    //t.detach();//子线程和主线程分离，主线程不再干预子线程的运行，无法获取子线程的执行结果

    //方式二：基于任务
    auto fut = std::async(doAsyncWork);
    std::cout<<"fut: "
    //有返回值，自然就可以用返回值判断执行结果
    /**
     * @brief 
     *好处是什么呢？
      如果申请的软件线程数量多于系统可以提供的，调用std::thread会抛出异常，然而调用std::async时
      系统不保证会创建一个新的软件线程，相反，它允许调度器把指定函数（doAsyncWork）运行在请求doAsyncWork
      结果的线程中，例如，对fut调用了get或者wait的线程，如果系统发生了超订或线程耗尽，合理的调度器就可以
      利用这个自由度
     * 
     */

}

//两个效果一样的
auto fut1 = std::async(doAsyncWork);//采用默认启动策略运行doAsyncWork
//采用或者异步或者推迟的方式运行doAsyncWork
auto fut2 = std::async(std::launch::async |
                         std::launch::deferred, doAsyncWork);

//如果在给定线程 t上执行 以上语句，会发生以下三种可能
/**
 * @brief 
 *     
 *  doAsyncWork 认为是 f
 * 1， 无法预知 f是否会和 t并发运行，因为 f 可能会被调度为推迟运行
 * 
 * 2，无法预知f是否运行在与调用 fut的get或wait函数的线程不同的某线程之上。如果那个线程是t,那就是说无法预知f是否运行
 * 在与t不同的某线程之上
 * 
 * 3，连f是否允许这件起码的事情都是无法预知的，这个因为无法保证在程序的每条路径上，fut的get或wait都会得到调用
 * 
 * @return int 
 */

using namespace std::literals;
void f()//f睡眠1s后返回
{
    std::this_thread::sleep_for(1s);
    sys ++;
    std::cout<<"f(): "<<sys<<std::endl;
}

//测试3
//真正以异步方式启动f
auto fut3 = std::async(std::launch::async,f);
if (fut3.wait_for(0s) == std::future_status::deferred)
{
    //如果任务被推迟了, 则使用fut的wait或get以异步方式调用f
}
else
{
    //任务没被推迟
    while (fut3.wait_for(100ms) != std::future_status::ready)
    {
        //任务没被推迟，也未就绪，则做并发工作，直到任务就绪
        sys ++;
        std::cout<<"ready: "<<sys<<std::endl;
    }

}

//C++11
template<typename F, typename... Ts>
inline std::future<typename std::result_of<F(Ts...)>::type>
reallyAsync11(F&& f, Ts&&... params)
{
    //返回异步所需的期望值
    return std::async(std::launch::async, std::forward<F>(f), std::forward<Ts>(params)...);
}
//C++14
template<typename F, typename... Ts>
inline auto
reallyAsync14(F&& f, Ts&&... params)
{
    //返回异步所需的期望值
    return std::async(std::launch::async, std::forward<F>(f), std::forward<Ts>(params)...);
}

//测试4
auto fut4 = reallyAsync11(f);

constexpr auto tenMillion = 10'000'000;

bool conditionAreSatisfied()
{
    return true;
    /**
     * @brief 
     * 如何在doWork中返回了false或者抛出了异常，那么在doWork的末尾调用std::thread型别对象t的析构函数时
     * 它会处于可联结合=状态，从而导致程序执行终止
     * 
     */
}

void performComputation( std::vector<int> &goodVals)
{
    for(auto i:goodVals)
        std::cout<<"i: "<<i<<std::endl;
}
bool doWork(std::function<bool(int)> filter, int maxVal = tenMillion)
{
    std::vector<int> goodVals;
    std::thread t([&filter, maxVal, &goodVals]
    {
        for(auto i=0; i <= maxVal; ++i)
        {
            if(filter(i))
            {
                goodVals.push_back(i);
            }
        }
    });

    //使用t的低值句柄设定t的优先级别
    auto nh = t.native_handle();

    //让t执行结束
    if(conditionAreSatisfied())
    {
        t.join();
        //计算实施
        performComputation(goodVals);
        return true;
    }
    //计算没有实施
    return false;
}

class ThreadRAII{
    public:
        enum class DtorAction{
            join,
            detach
        };
        //在析构函数中在t上采取行动a
        ThreadRAII(std::thread&& t, DtorAction a): action(a),t(std::move(t)){
        //1,std::thrrad型别对象是不可复制得，只接受右值型别
        }
        //可联结
        ~ThreadRAII()
        {
            if(t.joinable())
            {
                if(action == DtorAction::join)
                {
                    t.join();
                }
                else
                {
                    t.detach();
                }
            }
        }
        
        ThreadRAII(ThreadRAII&&) = default;
        ThreadRAII& operator=(ThreadRAII&&) = default;

        std::thread& get(){
            return t;
        }

    private:
        DtorAction action;
        std::thread t;//在成员列表得最后声明std::thread型别对象
};

bool doWork2(std::function<bool(int)> filter, int maxVal = tenMillion)
{
    std::vector<int> goodVals;
    ThreadRAII t(std::thread([&filter, maxVal, &goodVals]{
        for(auto i=0; i <= maxVal; ++i)
        {
            if(filter(i))
            {
                goodVals.push_back(i);
            }
        }
    }),
    ThreadRAII::DtorAction::join
    );

    //使用t的低值句柄设定t的优先级别
    auto nh = t.get().native_handle();

    //让t执行结束
    if(conditionAreSatisfied())
    {
        t.get().join();
        //计算实施
        performComputation(goodVals);
        return true;
    }
    //计算没有实施
    return false;
}


bool filter(int i)
{
    if(i < 3)
        return true;
    return false;
}

int main()
{
    //测试1
    doWork(filter);

    //测试2
    doWork2(filter);
}

//讨论这样一种情况：期望值位于信道的一端，被调方把结果通过该信道传输给调用方
//被调方，通常以异步方式运行把其计算所得的结果写入信道，通常经由一个std::promise型别对象，而调用方则使用一个期望值来读取该结果

        期望值                                        std::promise
调用方<------------------------------------------------------------ 被调方

//被调方的结果要存储在哪里呢？
/**
 * @brief 
 * 1，在调用方唤起对期望值的 get 之前，被调方可能已经执行完毕，因此结果不会存储在被调方的 std::promise型别对象里
 * 因为那个对象，对于被调方来说是个局部量，在被调方结束后会实施析构
 * 
 * 2，该结果也不能存储在调用方的期望值中，因为可能会从 std::future型别对象出发创建 std::shared_future型别对象，
 * 因此把被调方结果的所有权从 std::future型别对象转移到 std::shared_future型别对象，而后者可能会在原始的 std::futrue析构之后复制多次
 * 
 */

//因此，被调用的结果存储在一个叫 共享状态 的地方

        期望值                   共享状态                               std::promise
调用方<-------------------------被调方结果----------------------------------- 被调方

//期望值的析构行为是由与其关联的共享状态决定的
/**
 * @brief 
 * 1，指涉由  std::aysnc 启动的未推迟任务的共享状态的最后一个期望值会保持阻塞，直到该任务结束。
 * 本质上，这样一个期望值的析构函数是对底层异步执行任务的线程实施了一次隐式 join
 * 
 * 2，其他所有期望值对象的析构函数只仅仅将期望值对象析构就结束了。 对于底层异步运行的任务，类似
 * 对线程实施了一次隐式 detach。对于那些被推迟任务而言，如果这一期望值是最后一个，也就意味着被推迟的任务
 * 将不会有机会运行了
 * 
 */

//常规行为析构函数
//仅仅会析构期望对象，她不会针对任何东西实施 join，也不会从任何东西实施 detach，也不会对运行任何东西，仅仅会析构期望的成员变量

//非常规行为析构函数
//行为的具体表现为阻塞直到异步运行的任务结束，从效果上看，这相当于针对正在运行的 std::async所创建的任务的线程实施了一次隐式 join
//必须满足以下三点，才发挥非常规行为析构函数的作用
/**
 * @brief 
 * 1，期望所指涉的共享状态是由于调用了 std::async 才创建的
 * 
 * 2，该任务的启动策略是 std::launch::async，这既可能是运行时系统的选择，也可能是在调用std::async时指定的
 * 
 * 3，该期望是指涉到该共享状态的最后一个期望，对于 std::future型别对象，这一点总成立。但是 对于 std::shared_futrue型别对象而言，
 * 在析构时如果不是最后一个指涉到共享状态的期望，则它会遵守常规行为准测，仅仅析构其成员变量
 * 
 */

//问题1
//期望的API没有提供任何办法判断其指涉的共享状态是否诞生于 std::async 的调用，所以给定任意期望对象的前提下，它不可能知道自己是否会在析构
//函数中阻塞到异步任务执行结束

//该容器的析构函数可能会在其析构函数中阻塞，因为它所持有的期望中可能会有一个或多个指涉到经由 std::async启动未推迟任务所产生的共享状态
std::vector<std::future<void>> futs;
class Widget{ //Widget型别对象可能会在其析构函数中阻塞，除非有办法分析程序逻辑判定给定的期望值不满足触发非常规析构行为条件
    public:
        ...
    private:
        std::shared_future<double> fut;
}

//解决问题
//std::packaged_task型别对象会准备一个函数或其他可调用的对象，以供异步执行，把结果放入共享状态
{
    //待运行函数
    int calcValue();
    //给calcValue加上包装使之能以异步方式运行
    std::packaged_task<int()> pt(calcValue);//https://www.cnblogs.com/haippy/p/3279565.html
    //取得pt的期望
    auto fut = pt.get_future();//此时我们知道期望对象 fut没有指涉到由 std::async调用产生的共享状态，所以它的析构函数将表现为常规行为
    //但是 std::packsgaed_task不能复制，将pt传递给 std::thread的构造函数一定要将它强制转型到右值
    std::thread t(std::move(pt));

    ......

    /**
     * @brief 
     * 这个地方 t 的命运如下
     * 
     * 1，未对 t实施任何操作，其作用域结束点是可联结的，而这将导致程序终止
     * 
     * 2，针对 t实施了 join，在此情况下 fut无需再析构函数中阻塞，因为在调用的代码已经有过join
     * 
     * 3，针对 t 实施了 detach
     * 
     * 换句话说，当你的期望值所对应的共享状态是 由 std::packaged_task产生的，则通常不用采用特别析构策略
     * 
     */
} //代码块结束

std::condition_variable cv;//事件得条件变量
 std::mutex m;//在运用cv时给它加得互斥量

//检测任务得代码
{
    /**
     * @brief 
     * 检测事件
     */

    cv.notify_one();//通知反应任务 一个
    //cv.notify_all();//通知反应任务，多个
}

//反应任务得代码
//准备反应
{
    //临界区域开始
    std::unique_lock<std::mutex> lk(m);//为互斥量加锁
    cv.wait(lk);//等待通知到来

    /**
     * @brief 
     * 这对事件作出反应得操作
     * 
     */

    //临界区域结束，通过lk得析构函数为m解锁
}
//继续等待反应，m已经解锁

std::atomic<bool> flag(false);//共享得布尔标志位
{
    //检测线程 通知反应任务
    flag = true;
}

{
    //反应线程会轮询标志位
    while (!flag)
    {
        /* code */
    }
}

//检测任务
std::condition_variable cv;
std::mutex m;
bool flag(false);
{
    std::lock_guard<std::mutex> g(m);//由g的构造函数锁定m
    flag = true;//通知反应任务，第一部分
}//由g的析构函数为m解锁
cv.notify_one();//通知反应任务，第二部分

//反应部分
{
    std::unique_lock<std::mutex> lk(m);
    cv.wait(lk,[]{
        return flag;
    })
}

std::promise<void> p;//信道的约值

//检测任务
{
    //检测事件
    p.set_value();//通知反应任务
}

//反应任务
{
    //准备反应
    p.get_future().wait();//等待p对应的期望值
    //针对事件做出反应
}

std::promise<void> p;
void react(){
    //反应任务函数
}

//检测任务函数
void detect()
{
    std::thread t([]{ //创建线程
        p.get_future().wait();//暂定t到其期望被设置
        react();
    });
    //在这里t处于暂定状态，在调用react之前
    
    p.set_value();//取消暂停t，调用react

    //做其他工作

    t.join();//设置t为不可连结状态
}

std::promise<void> p;
//线程可以处理多个反应任务了
void detect()
{
    //sf的型别是 std::shared_future<void>
    auto sf = p.get_future().share();
    //反应任务的容器
    std::vector<std::thread> vt;

    for(int i=0; i < 10; ++i)
    {
        vt.emplace_back([sf]{
            sf.wait();
            react();
        });//sf局部副本之上的wait
    }

    //

    p.set_value();//让所有线程取消暂停

    //

    for(auto& t:vt)
    {
        t.join();//把所有线程设置不可联结状态
    }
}

void doAsyncWork1()
{   
    ++ac;
    ++vc;
    std::cout<<"doAsyncWork: "<<"ai: "<<ai<<" vi: "<<vi<<" ac: "<<ac<<" vc: "<<vc<<std::endl;
}

void doAsyncWork2()
{   
    ++ac;
    ++vc;
    std::cout<<"doAsyncWork: "<<"ai: "<<ai<<" vi: "<<vi<<" ac: "<<ac<<" vc: "<<vc<<std::endl;
}

    //情况1：std::atomic
   // std::atomic<int> ai(0);//将 ai视为 0
    ai = 10;//将ai 原子地设置为10
    std::cout << ai <<std::endl;//原子地读取 ai的值
    ++ai;//原子地将 ai自增为 11
    --ai;//原子地将ai自减为10

    //在以上语句执行期间，其他读取 ai的线程可能只会看到它取值为 0 ，10 或 11,而不可能由其他值，当然，前提假设这是
    //修改 ai值得唯一线程

     auto fut1 = std::async(doAsyncWork1);

    //情况2：volatile 不能提供任何保障
    //volatile int vi(0);//初始为0
    vi = 10;//将vi设置为10
    std::cout<<vi;//读取vi得值
    ++vi;//将vi自增为11
    --vi;//将vi自减为10

    auto fut2 = std::async(doAsyncWork1);

    //但是，在这段代码执行期间，如果其他线程正在读取 vi得值，他们可能会看到任何值，例如 -12， 68，4044040040.因此
    //会出现在即非std::atomic，也非由互斥量保护得同时读写操作，数据竞险

    //情况3，再次对比
    //考虑两者由多个线程执行自增得简单计数器，都初始化为0
    // std::atomic<int> ac(0);
    // volatile int vc(0);
    //之后，在两个同时运行得线程中将两者各自增一次

    /**
     * @brief 
     * 
     *  线程1                 线程2
     * 
     *  ++ac                 ++ac
     *  ++vc                 ++vc
     * 
     * 1, std::atomic型别对象的值一定是2，每次自增都是原子操作
     * 2，vc的值不一定是2，自增可能会不以原子方式发生，每次自增包括读取vc的值，自增读取的值，并将结果写回vc
     */

//情况4
//假设一个任务负责计算第二个任务所需的重要值，当第一个任务已经计算出该值时，它必须把这个值通信到第二个任务
int computeValue()
{

}
std::atomic<bool> val(false);
auto tmp = computeValue();//计算值
val = true;
/**
 * @brief 
 * 1, 使用 atomic可以保证 tmp的赋值一定在 val = true之前，否则编译器可能将这些不相关的赋值重新排序
 * 
 * 2，相反，将atomic改成   volatile bool val(false); 
 * 不会给代码施加同样的重新排序的约束，可能会改变赋值顺序，机器代码阻止底层硬件在其内核上的顺序
 * 
 */

//情况5
//volatile难道就没有用武之地了嘛？即使对并发无用，也会告诉编译器，正在处理的内存不具备常规行为
/**
 * @brief 
 * 
 * 1， 常规内存
 *   1,1 如果你向某个内存位置写入了值，该值会一直保留在那里，直到它被覆盖为止
 *   1,2 如果向某内存位置写入某值，期间未读取该内存位置，然后再次写入该内存位置，则第一次写入可以消除，因为其写入结果从未使用过
 *     auto y =x;
 *         y =x;
 * 
 * 2，特种内存
 *  最常见的是用于内存映射 I/O的内存，这种内存的位置实际上是用于与外部设备通信，而非用于读取或写入常规内存（RAM）
 *    比如 1 中的例子，x对应于由温度传感器报告的值，则 x的第二次读取操作并非多余，因为在第一次和第二次读取之间，温度可能已经改变
 * 
 * 而 volatile的用处就是告诉编译器，正在处理的是特种内存，不要对在此内存上的操作做任何优化，此时std::atomic就失去了作用
 * 
 * 但是，两者可以结合使用，如果 vai对应由多个线程同时访问的内存映射的 I/O 位置，会有用
 * volatile std::atomic<int> vai;// 针对
 * 
 * @return int 
 */
volatile int x;
auto y = x;//读取x
y = x;//再次读取x，不会被优化掉
x =10;//写入x，不会被优化掉
x=20;//再次写入x

//方式一：为了效率 左值实施复制，右值实施移动
class Widget{
    public:
        void addName(const std::string& newName)
        {
            names.push_back(newName);//接收左值，对其实施复制
        }

        void addName(std::string&& newName)
        {
            names.push_back(std::move(newName));//接收右值，对其实施移动
        }
    private:
        std::vector<std::string> names;
};
//局限性：需要撰写两份函数声明，两份函数实现，维护多

//方式二：接收万能引用的函数模板
class Widget{
    public:
        template<typename T>
        void addName(T&& newName)
        {
            names.push_back(std::forward<T>(newName));
        }
    private:
        std::vector<std::string> names;
};
//局限性：作为模板，addName的实现必须在头文件中。并且有些函数不适合通用引用方式传递 std::string

//方式三：按值传递
//此时你要放弃你身为C++程序员学到的第一条规则：避免按值传递用户定义型别对象
//但是本例可能是个特例，重点看看为什么？
class Widget{
    public:
       void addName(std::string newName)
       {
        names.push_back(std::move(newName));//即接收左值也接收右值，对后者实施移动
       }
     private:
        std::vector<std::string> names;
};

Widget w;
std::string name("Bart");
w.addName(name);//在调 addName时传入左值，对newName实施的是复制构造

w.addName(name + "jenne");//在调addName时传入右值，对newName实施的是移动构造

class Widget{
    public:
        void setPtr(std::unique_ptr<std::string>&& ptr)
        {
            p = std::move(ptr);
        }
    private:
        std::unique_ptr<std::string> p;
};

Widget w;
w.setPtr(std::make_unique<std::string>("C++"));
//std::make_unique返回右值 std::unique_ptr<std::string>会以右值引用方式传递给setPtr，在那里它被移入数据成员p，总成本是一次移动
//如果改成按值传递：同一调用会导致针对形参 ptr实施移动构造后，再将ptr移入数据成员p，这样总成本是两次移动

class Password{
    public:
        explicit Password(std::string pwd)： text(std::move(pwd)){} //按值传递 ，对 text实施构造
        //构造函数采用按值传递会导致std::string 的移动构造成本

        void changeTo(std::string newPwd) 
        {
            text = std::move(newPwd);//按值传递，对 text实施赋值
        }
    private:
        std::string text;
};

std::string initPwd("aaaaaaaaaaaaaaaaaaa");
Password p(initPwd);

//修改密码
std::string newPwd = "advsdvsdvs";
p.changeTo(newPwd);//采用赋值操作修改text，会导致成本增加
//旧密码比新密码更长，所以不需要实施任何内存分配和回收，采用重载途径，不会发生任何动态内存管理行为

//基类
calss Widget{

};
//派生类
calss SpWidget:public Widget{

};
//未任何Widet而设计的函数，包括派生型别会受到切片问题的侵害
void processWidget(Widget w);
SpWidget sw;
//processWidget看到的只是一个 Widget而非 SpWidget型别的对象
processWidget(sw);

//情况1
std::vector<std::string> vs;//持有std::string型别对象的容器
vs.push_back("xyzzy");//添加字符串字面量

//但是，容器持有的是 std::string型别对象，传入的却是字符串字面量，不是std::string

//std::vectoe的push_back针对左值和右值给了不同的重载版本
template<class T,class Allocator=allocator<T>>
class vector{
    public:
        void push_back(const T& x);//插入左值
        void push_back(T&& x);//插入右值
};

//因此在上面 push_back的调用语句中，编译器会看到实参型别 （const char [6]）与 push_back （std::string的引用型别）
//接受的形参型别之间的不匹配。
//解决办法是：从字符串字面量出发创建std::string型别的临时对象，并将该临时对象传递给 push_back，换句话是，看作是这样

vs.push_back(std::string("xyzzy"));//创建std::string型别的临时对象，并将其传递给push_back

//但是，性能问题需要考虑：以上调用了两次构造和一次析构，完整执行流程如下

//因此，有没有办法将字符串字面量直接传递给步骤2那段std::vector内构造std::string型别对象的代码，就可以避免先构造再析构tmp了
//有，利用 emplace_back ： 它使用传入的任何实参在 std::vector内构造一个 std::string，不会涉及任何临时对象
vs.emplace_back("xyzzy");//直接从 “xyzzy” 出发在 vs内构造 std::string型别对象

//同样，即使插入函数并不要求创建临时对象的情况，也可以使用置入，效率一样
std::string qq("aaaaa");
vs.push_back(qq);//在vs的尾部复制了aaaa
vs.emplace_back(qq);//同上

//第一个问题：资源管理
std::list<std::shared_ptr<Widget>> ptrs;
//自定义删除器函数
void killWidget(Widget* pw);
//插入代码
pts.push_back(std::shared_ptr<Widget>(new Widget,killWidget));
//也可以这样
pts.push_back({new Widget,killWidget});

//在调用push_back之前都会创建一个 std::shared_ptr型别的临时对象
//push_back的形参是个 std::shared_ptr型别的引用，所以必须存在一个std::shared_ptr型别对象来让该形参指涉到
//如选用emplace_back，本可以避免创建 std::shared_ptr型别的临时对象，但是有时候有临时对象的收益超过成本

/**
 * @brief 
 * 1，构造一个 std::shared_ptr<Widget>型别的临时对象，用来持有 从 “new Widget”返回的裸指针，该对象成为tmp
 * 
 * 2，push_back会按引用方式接受tmp，在为链表节点分配内存以持有tmp的副本的过程中，抛出了内存不足的异常
 * 
 * 3，该异常传播到 push_back之外，tmp被析构，作为 给 Widget兜底的，指涉到它并对其施加管理的 std::shared_ptr<Widget>
 * 型别对象会自动释放该Widget，调用 killWidget达成该目的
 * 
 * @return int 
 */

//但是，如果调用的是emplace_back，会发生什么
ptrs.emplace_back(new Widget,killWidget);

/**
 * @brief 
 * 1, 从 new Widget返回的裸指针被完美转发，并运行到 emplace_back内为链表节点分配内容的执行点，之后该内存分配失败，并
 * 抛出了内存不足的异常
 * 
 * 2，该异常传播到了 emplace_back之外， 作为唯一可以获取堆上Widget的抓手的罗指针，却丢失了，那个Widget都发生了泄露
 * 
 * 
 * @return int 
 */

//正确的做法
//从 new Widget中获取指针并将其在独立语句中转交给资源管理对象，然后该对象作为右值传递给你最初想要向其传递 new Widget的函数
//push_back
std::shared_ptr<Widget> spw(new Widget,killWidget);//构造Widget并用spw管理它
ptrs.push_back(std::move(spw));//以右值形式添加spw
//emplace_back
ptrs.emplace_back(std::move(spw));