标签:11 std int lock c++ 对象 guard mutex 多线程
https://www.youtube.com/watch?v=3ZxZPeXPaM4 学习视频
数据争用
简单来说就是存在多个线程同时对某个共同的对象进行读写(至少有一个线程在做写操作),造成读取这个对象时的结果不可预测
如下
int num = 0;
void func(int &v)
{
for (int i = 0; i < 100000; ++i)
{
num = num + 1;
v++;
}
}
int main()
{
int v = 0;
std::vector<std::thread> ts;
for (int i = 0; i < 100; ++i)
{
ts.push_back(std::thread(func, std::ref(v)));
}
for (int i = 0; i < 100; ++i)
{
ts[i].join();
}
std::cout << num << ", " << v << std::endl;
return 0;
}
cout结果并不是10 000 000, 10 000 000
使用Mutex控制对象的读写
在对象的读写操作之前调用mutex::lock即可(记得不需要持有对象时调用mutex::unlock)
...
std::mutex mu;
void func()
{
...
mu.lock();
num += 1;
v += 1;
mu.unlock();
}
...
std::lock_guard
在mutex的lock-unlock块里如果抛出异常,那么unlock就不会被调用(或者忘记调用unlock也是有可能的),
这时可以考虑使用lock_guard:
...
{
std::lock_guard<std::mutex> guard(mu);
v++;
num++;
}
...
我感觉应该是lock_guard内部将会持有mutex,然后在析构函数里尝试调用mutex的unlock方法
读写控制的对象有没有完全被锁定
针对上面的例子,有一个全局变量num,和一个局部变量v,虽然在各个子线程里都用mutex进行了读写控制;
但是在主线程里并没有,仍然可以在main里面随意的处理这两个共享对象;
处理方法就是将要保护的资源对象和mutex绑定在一起,保证每次使用资源对象前必须通过mutex
如下:
class LogFile {
std::mutex m_mutex;
ofstream f;
LogFile() {
f.open(...);
}
void shared_print(string id, int value) {
std::lock_guard<mutex> guard(m_mutex);
f << id << ", " << value << endl;
}
// ofstream &getStream() { return f; }
}
上面这个例子,切记不能将LogFile的f对象暴露出来,就像最后一行注释那样
当然如果返回的是ofstream是没问题的;
还有一些其它情况可能“意外”暴露LogFile::f,如下:
void LogFile::processf(void fun(ofstream&))
{
fun(this->f);
}
这里就“不小心”将f对象引用传递给了某个函数fun,在fun里,LogFile::f就失去了mutex的保护
小结
- 使用mutex来控制资源对象的读写
- 不要将内部资源对象暴露出Wrapper类
- 注意接口设计的合理性
标签:11,std,int,lock,c++,对象,guard,mutex,多线程 来源: https://www.cnblogs.com/ChenLambda/p/11728371.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。