原子变量 Vs。原子操作
假设我有两个彼此相关的共享变量 - a 和 b。当多个应用程序共享这些共享变量时，对它们的访问需要是原子操作，否则关系可能会中断。因此，为了确保互斥，我将把它们的修改放在受锁保护的关键部分下。
critical_code
{
P(mutex)
a := something
b := something
V(mutex)
}
假设我的硬件/操作系统/编译器支持原子变量。然后我将上面的代码修改如下。
code
{
atomic a := something
atomic b := something
}
当多个应用程序访问时，此代码能否确保互斥？
此致，
斯里尼瓦斯·纳亚克
Lets say I have two shared variables - a and b - that are related to each other. When multiple applications share these shared variables, access to them needs to be an atomic operation, otherwise the relation may break. So to ensure mutual exclusion, I'll put their modification under a critical section protected by lock.
critical_code
{
P(mutex)
a := something
b := something
V(mutex)
}
Lets say my hardware/OS/compiler supports atomic variables. Then I modified my above code as follows.
code
{
atomic a := something
atomic b := something
}
Can this code ensure mutual exclusion, when accessed by multiple applications?
Sincerely,
Srinivas Nayak
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，你仍然需要一个关键部分。虽然每个变量的更新是原子的，但这仍然不能保证一个进程只修改一个变量但另一个进程已经在读取不一致状态的情况。
仅当足以知道每次写入和每次读取都是原子时，您才依赖原子变量 - 即，如果您知道当一个进程更新变量时另一个进程不会读取部分更改的变量，您就已经很高兴了。
因此，原子变量对于每个变量来说都是原子的，而不是对于一组变量来说是原子的。
No, you still need a critical section. While update of each variable is atomic, this still doesn't warrant against situations when one process has only midified one variable but the other is already reading the inconsistent state.
You only rely on atomic variables when it's enough to know that every one write and every one read is atomic - i.e. you're already happy if you know that when one process is updating the variable the other will not read a partially changed variable.
So atomic variable is atomic per one variable, not per set of variables.