我有指向其他对象中元素的指针。这样做安全吗？我知道当vector需要更多空间时，它会移动所有对象，因此指针将无效。
mylist.push_back(MyObj(1));
if(someCond)
{
_myLastObj = &mylist.back();
}
_myLastObj 的类型为 MyObj*
如果我使用vector，对象将被移动到不同的位置，指针将指向垃圾。使用列表是否安全？
std::list 元素的指针仅在从列表中移除相应元素时才会失效。由于您的代码从未从列表中删除任何内容，因此您的指针是安全的。关于为什么需要锁的具体原因，请考虑例如list::push_back可能按以下顺序执行：
如果您的读取线程在步骤 2 和 3 之间进入，则它将从先前的尾部到达新节点，然后尝试跟随未初始化的指针。炸掉了。
总的来说，需要同步是因为这是唯一保证写线程中所做更改以任何合理顺序（或根本）发布到读取线程的方法。
如果您想象不同线程在不同的星球上运行，每个星球都有自己的程序内存副本，并在使用同步对象（或 C++11 中的原子变量）时将更改传输给彼此（a），加上（b）当您不使用同步对象但传输某些特定的部分更改会破坏您的代码时（例如两个字对象的一半或在这种情况下需要以特定顺序发生的两个指针写入之一），则您的代码应该是正确的。有时，这种模型比严格必要的更保守，并导致更慢的代码。但是不太保守的模型依赖于线程系统和内存模型的实现特定细节。
boost::s_list目前没有执行任何此类操作，则可以这样做。一般来说，这是不安全的。如果您想要一个无锁队列，请搜索一个，但list和s_list不是这样的。 - Steve Jessoplist的代码，使得你的代码可用，但这对你没有任何帮助。因为它并不能保证你的代码的安全性。 - Steve Jessop#include <iostream>
#include <list>
#include <mutex>
#include <thread>
using namespace std;
list<int> unsafe_list;
class : public list<int> {
mutex m;
public:
void push_back(int i) {
lock_guard<mutex> lock{m};
list<int>::push_back(i);
}
} safe_list;
template <typename List> void push(List &l) {
for (auto i = 0; i < 10000; ++i)
l.push_back(0);
}
void report_size(const list<int> &li, char const *name) {
size_t count{};
for (auto && i : li) ++count;
cout << name << endl;
cout << "size() == " << li.size() << endl;
cout << "count == " << count << endl;
}
int main() {
auto unsafe = []() { push(unsafe_list); };
auto safe = []() { push(safe_list); };
thread pool[]{
thread{unsafe}, thread{unsafe}, thread{unsafe},
thread{safe}, thread{safe}, thread{safe},
};
for (auto &&t : pool)
t.join();
report_size(unsafe_list, "unsafe_list");
report_size(safe_list, "safe_list");
}
unsafe_list
size() == 19559
count == 390
safe_list
size() == 30000
count == 30000
这个链表的底层结构和算法没有什么有趣或奇怪的地方，但是有一些需要提到的C++实现细节。首先，列表的所有节点都派生自一个仅存储两个指针的共同基类。通过这种方式，列表的所有行为都被封装起来了。实际的节点除了从基类派生之外，还是带有非静态数据成员__gnu_cxx::__aligned_membuf<_Tp> _M_storage的结构体。这些节点知道列表的value_type，并从重新绑定到_List_node<_Tp>的allocator_type中派生出来。这些节点的目的是获取和释放列表的存储空间，并使用它们的基类来维护数据的结构。(我推荐这篇论文来解释迭代器中类型如何被分离，它可能会阐明为什么某些事情被实现的方式http://www.stroustrup.com/SCARY.pdf。对于受虐狂者，看看这位巫师解释美丽的噩梦——c++分配器https://www.youtube.com/watch?v=YkiYOP3d64E）。
有一个共同的（类型无关的）基类节点的主要优点是可以随意链接任意类型的节点。如果不加控制地做，这并不会有太大帮助，但他们以一种受控的方式使用它。"尾节点"不是value_type类型，而是size_t类型。尾节点保存列表的大小！（我花了几分钟才弄清楚发生了什么，但这很有趣，所以没什么大不了的。这样做的主要好处是每个存在的列表都可以有相同类型的尾节点，因此处理尾节点的代码重复较少，并且列表只需要一个非静态数据成员就可以完成它需要做的事情）。
因此，当我将节点推到列表的后面时，end()迭代器被传递给以下函数：
template<typename... _Args>
void
_M_insert(iterator __position, _Args&&... __args)
{
_Node* __tmp = _M_create_node(std::forward<_Args>(__args)...);
__tmp->_M_hook(__position._M_node);
this->_M_inc_size(1);
}
_M_create_node()最终使用正确的分配器获取节点的存储空间，然后尝试使用提供的参数在那里构建元素。 _M_hook()函数的“要点”是将指针指向它们应该指向的指针，并在此处列出：
void
_List_node_base::
_M_hook(_List_node_base* const __position) _GLIBCXX_USE_NOEXCEPT
{
this->_M_next = __position;
this->_M_prev = __position->_M_prev;
__position->_M_prev->_M_next = this;
__position->_M_prev = this;
}
void _M_inc_size(size_t __n) { *_M_impl._M_node._M_valptr() += __n; }
size_t的尾节点，因此，可以猜测_M_impl._M_node._M_valptr()会检索指向该数字的指针，然后将其加上正确的数量。_M_hook()和_M_inc_size()函数中进入了数据竞争(https://en.cppreference.com/w/cpp/language/memory_model)。假设T是尾部，B是“后方”，我们想要将1推到后方。也就是说，我们有列表(片段)B <-> T，我们想要B <-> 1 <-> T。最终，1在T上调用_M_hook，然后发生以下事件：
1向前指向T1向后指向BB向前指向1T向后指向11和2在同一个列表的不同线程上被推回。完全有可能对于1，步骤(1)和(2)完成，然后2被完全推回，接着(1)必须完成。这种情况下会发生什么？我们有列表B <-> 2 <-> T，但是1指向B和T，因此当它们的指针被调整时，列表看起来像B <-> 1 <-> T，这是一种内存泄漏。基本上，由于被增加的值不是“本地”变量，它的值必须被读入寄存器，然后将一个值添加到该值，然后将该值存回变量中。让我们来看一些汇编代码（我的汇编能力不强，请勿介意如果您有更正意见）。考虑以下程序：
int i{};
int main() {
++i;
}
Disassembly of section .text:
0000000000000000 <main>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # a <main+0xa>
a: 83 c0 01 add $0x1,%eax
d: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 13 <main+0x13>
13: b8 00 00 00 00 mov $0x0,%eax
18: 5d pop %rbp
19: c3 retq
4: 将i的值移动到寄存器eax中。将0x1添加到eax，然后将eax移回i中。那么这与数据竞争有什么关系呢？再看一下更新列表大小的函数：
void _M_inc_size(size_t __n) { *_M_impl._M_node._M_valptr() += __n; }
当前存在一个线程在操作列表时，我们很有可能会将当前列表大小加载到寄存器中，而另一个正在操作该列表的线程可能会干扰我们的操作。因此，我们在寄存器中保留了旧的列表大小值，但我们必须保存该状态并将控制权转移给其他人。也许他们成功地向列表中添加了一项并更新了其大小，然后将控制权还给我们。我们恢复我们的状态，但是我们的状态不再有效！我们有了列表的旧大小，然后将其增加，并将其值存回内存，忘记了其他线程执行的操作。
正如我之前提到的，在上面的程序中，“i”的“局部性”起到了作用。 这个重要性可以从以下内容看出：
int main() {
int i{};
++i;
}
Disassembly of section .text:
0000000000000000 <main>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp)
b: 83 45 fc 01 addl $0x1,-0x4(%rbp)
f: b8 00 00 00 00 mov $0x0,%eax
14: 5d pop %rbp
15: c3 retq
可以看到，没有将任何值存储到寄存器中，也没有将寄存器推入某个变量。不幸的是，据我所知，这并不是一种避免并发问题的好方法，因为多个线程对同一变量的操作必须通过内存访问进行，而不仅仅是通过寄存器。我很快就会超出我的能力范围，但我非常确定这是真的。下一个最好的选择是使用atomic<int>，但这个该死的东西已经太长了。