【问题标题】:Access an object with automatic storage duration from another thread从另一个线程访问具有自动存储持续时间的对象
【发布时间】:2019-04-27 22:03:39
【问题描述】:

我偶然发现了这个问题:Thread access to stack of another thread。链接的问题是关于纯 C 的,但我的主要语言是 C++,所以我试图找出相同的规则是否适用于 C++。

我在 C11 草案N1570 中找到了这一部分:

6.2.4.5 其标识符声明为无链接且无链接的对象 存储类说明符 static 具有自动存储持续时间,如 做一些复合文字。试图间接的结果 从其他线程访问具有自动存储持续时间的对象 比与对象关联的对象是 实现定义

我相信 C++20 草案 N4810 的相应部分是 [basic.stc.auto],它没有提到这种情况。 C++11 草案在这部分的文字与 C++20 完全相同。

[intro.multithread]下我找到了这句话带脚注:

程序中的每个线程都可能访问程序中的每个对象和函数。

具有自动或线程存储持续时间 (6.6.5) 的对象是 与一个特定线程相关联,并且可以由 不同的线程只能通过指针或引用间接 (6.7.2)。

所以我假设在 C++ 中从另一个线程访问具有自动存储持续时间的对象总是没问题的(直到对象的生命周期结束并且当然没有数据竞争)。对吗?

【问题讨论】:

  • 我不知道为什么一个线程不能将指针或对局部变量的引用传递给另一个线程;当然,假设生命周期和数据竞争问题得到了解决。它在 C++ 中非常常规地完成 - 参见例如an example here,尤其是std::thread t3(f2, std::ref(n));
  • @IgorTandetnik,我知道。这就是为什么当我得知它是用纯 C 语言定义的实现时,我如此惊讶的原因。
  • 不管怎样,该文本在我最新的 C2x 草案中。

标签: c++ multithreading language-lawyer lifetime


【解决方案1】:

您是对的,您为 C++ 引用的行有效地确定了 C++ 程序中的所有线程都看到相同的地址空间。 C++ 对象模型的基石之一是每个活着的对象都有一个唯一的地址[intro.object]/9。基于[intro.multithread]/1,您可以将在一个线程的自动或线程本地存储中创建的对象的指针或引用传递给另一个线程,并从第二个线程访问该对象,只要该对象保证存在并且不存在数据竞赛……

有趣的是,C 标准似乎没有明确给出类似的保证。然而,不同的对象有不同的地址,而且从程序中每个线程的角度来看,一个对象的地址是相同的,这似乎仍然是语言规则隐含的、必然的结果。 C18 指定活动对象的地址不会改变 [6.2.4/2],任何对象指针都可以与指向 void [6.5.9/2] 的指针进行比较,并且两个指针比较相等当且仅如果它们指向同一个对象 [6.5.9/6]。存储类不是指针类型的一部分。因此,指向一个线程的自动存储中的对象的指针必须与指向另一个线程的自动存储中的某个其他对象的指针以及指向具有不同存储持续时间的某个对象的指针进行比较。并且在某个线程的自动存储中,任何两个指向同一个对象的指针必须比较相等,无论哪个线程以何种方式从哪里获得这些指针。因此,指针的值在不同的线程中并不意味着不同的东西。即使它可能是实现定义的给定线程是否可以通过指针实际访问另一个线程的自动存储中的对象,我也可以,例如,创建一个全局void*,为其分配一个指向自动存储对象的指针从一个线程,并且,给定必要的同步,让另一个线程观察这个指针并将它与另一个指针进行比较。该标准向我保证,只有当我将它与指向同一个对象的另一个指针进行比较时,比较才能为真,即另一个线程的自动存储中的同一个对象,并且在这种情况下它必须是真的......

我无法为您提供决定将其保留为实现定义的确切理由,一个线程是否可以访问另一个线程的自动存储中的对象。但是可以想象一个假设的平台,例如,出于安全原因,只有分配堆栈的线程才能访问该堆栈的页面。我不知道任何实际的平台会出现这种情况。然而,操作系统可以轻松做到这一点,即使在 x86 上也是如此。 C 已经基于一些关于地址模型的、可以说是相当强的假设。我认为 C 标准委员会只是试图避免在此之上添加更多限制是一个很好的猜测……

【讨论】:

    猜你喜欢
    • 2021-11-08
    • 2014-07-13
    • 2018-04-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-07-16
    • 1970-01-01
    相关资源
    最近更新 更多