当std :: lock_guard仍然在作用域内时,使用pthread_create创建线程是否安全?

C_user5

我有一个类似以下的函数,其中线程通过使用std::lock_guard互斥锁获取锁,然后通过写入文件ofstream

当当前文件大小增加最大大小时,我想创建一个独立的线程来压缩文件并终止。

我想了解通话的含义pthread_createstd::lock_guard仍然在范围之内。

安全吗?锁是否也将应用于新线程(我不希望如此)?

void log (std::string message)
{
    std::lock_guard<std::mutex> lck(mtx);

    _outputFile << message << std::endl;
    _outputFile.flush();
    _sequence_number++;
    _curr_file_size = _outputFile.tellp();

    if (_curr_file_size >= max_size) {
        char *lf = strdup(_logfile.c_str());
        // Create an independent thread to compress the file since
        // it takes some time to compress huge files.
        if (!_compress_thread) {
            pthread_create(&_compress_thread, NULL, compress_log, (void *)lf);
        }
    }
}

void * compress_log (void *arg) 
{
    pthread_detach(pthread_self());

    // Code to compress the file
    // ...

   { // Create a scope for lock_gaurd

       std::lock_guard<std::mutex> lck(mtx);
       _compress_thread = NULL;
   }
   pthread_exit(NULL);
}
生锈的

互斥锁在线程级别起作用,它仅影响使用它的线程。当线程锁定互斥锁时,可能会发生两件事:

  1. 互斥锁被解锁-它被锁定,线程继续执行。
  2. 互斥锁已被锁定-线程不会继续运行,但是要等待直到互斥锁被解锁。

您的新线程将运行该compress_log()函数,该函数根本不会访问互斥体。因此,无论互斥锁是否被锁定,它都将运行(在您的情况下,互斥锁将在log()退出时解锁)。


一个不相关的建议:使用std::thread代替pthread_create,这样您的应用程序将变得更加可移植:

    std::thread{ [lf] { compress_log(lf); } }.detach();

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章

尽管作用域范围很广,std :: lock_guard似乎仍提供线程安全性

C ++ std :: lock_guard作用域范围

通过使用“ std :: lock_guard <mutex>”引用返回共享对象是否安全?

if块内std :: lock_guard的范围

是否可以将std :: condition_variable与std :: lock_guard一起使用?

为什么多余的额外作用域块会影响std :: lock_guard行为?

在析构函数中保存std :: lock_guard是否安全?

std :: lock_guard如何比std :: mutex :: lock()更快?

std :: lock_guard还是std :: scoped_lock?

std :: lock_guard <std :: mutex> lock(m)是否有简写形式?

有条件使用std :: lock_guard

std :: unique_lock <std :: mutex>或std :: lock_guard <std :: mutex>?

std :: lock_guard不会解锁

std :: atomic_flag和std :: lock_guard

如何在std :: pair中返回std :: lock_guard

为什么std :: lock_guard / std :: unique_lock不使用类型擦除?

为什么在使用std :: adopt_lock后std :: lock_guard释放锁定?

当`std :: lock_guard <std :: mutex>`对象没有名称时的不同行为

std :: scoped_lock或std :: unique_lock或std :: lock_guard?

std :: lock_guard <std :: unique_lock <std :: mutex >>是有效还是推荐的?

在本地C中是否有类似于std :: lock_guard的东西?

在额外范围内包括std :: lock_guard

std :: lock_guard示例,解释其工作原理

std :: lock_guard导致未定义的行为

std :: lock_guard和#pragma ompcritical之间的区别

std :: lock_guard构造函数实例化顺序

为什么将std :: lock放在std :: lock_guard之前

不鎖定互斥鎖的 std::lock_guard 和 std::adopt_lock 行為

如何在不违反const正确性的情况下使用std :: lock_guard?