在我评论的代码库中,我发现了以下习语.
void notify(struct actor_t act) {
write(act.pipe, "M", 1);
}
// thread A sending data to thread B
void send(byte *data) {
global.data = data;
notify(threadB);
}
// in thread B event loop
read(this.sock, &cmd, 1);
switch (cmd) {
case 'M': use_data(global.data);break;
...
}
"抓住它",我对作者说,我的团队的一名高级成员,"这里没有内存障碍!你不能保证global.data将从缓存刷新到主内存.如果线程A和线程B将运行两个不同的处理器 - 这个方案可能会失败".
高级程序员咧嘴一笑,慢慢解释,仿佛在解释他五岁的男孩如何系鞋带:"听小男孩,我们在这里看到很多线程相关的错误,在高负载测试中,在真实客户中",他他停下来留下他长长的胡须,"但我们从来没有这个成语的错误".
"但是,它在书中说......"
"安静!",他立刻叫醒我,"也许理论上,它不能保证,但实际上,你使用函数调用的事实实际上是一个内存屏障.编译器不会重新排序指令global.data = data,因为它无法知道是否任何人在函数调用中使用它,并且x86架构将确保其他CPU在线程B从管道读取命令时将看到这段全局数据.请放心,我们有充足的现实问题需要担心.我们不需要在虚假的理论问题上投入额外的努力.
"请放心,我的孩子,你会理解将真正的问题与我需要获得博士的非问题分开."
他是对的吗？这在实践中真的不是问题(比如x86,x64和ARM)吗？
这是我所学到的一切,但他确实有一个长胡子和一个非常聪明的外观!
额外的积分如果你能告诉我一段代码证明他错了!
例如,假设我使用new分配一个struct,并将指针写入匿名管道的write端.
如果我从相应的读取端读取指针,我保证在结构上看到"正确"的内容吗？
同样令人感兴趣的是,unix上的socketpair()和通过windows上的tcp环回自连接的结果是否具有相同的保证.
上下文是一个服务器设计,它使用select/epoll集中事件调度
可以依赖外部I/O作为跨线程同步的一种形式吗？
具体来说,请考虑下面的伪代码,假设存在网络/套接字函数:
int a; // Globally accessible data.
socket s1, s2; // Platform-specific.
int main() {
// Set up + connect two sockets to (the same) remote machine.
s1 = ...;
s2 = ...;
std::thread t1{thread1}, t2{thread2};
t1.join();
t2.join();
}
void thread1() {
a = 42;
send(s1, "foo");
}
void thread2() {
recv(s2); // Blocking receive (error handling omitted).
f(a); // Use a, should be 42.
}
我们假设远程机器只发送数据,s2在接收到"foo"从s1.如果这个假设失败,那么肯定会产生未定义的行为.但如果它成立(并且没有其他外部故障发生,如网络数据损坏等),该程序是否会产生定义的行为？
"从不","未指定(取决于实现)","取决于send/recv实现提供的保证"是我期望的那种示例答案,最好是C++标准(或其他相关标准)的理由,例如POSIX for socket/networking).
如果"从不",则更a改为 …