c – 当std :: atomic :: is_always_lock_free为false时std :: atomic是否具有中断安全性?

前端之家收集整理的这篇文章主要介绍了c – 当std :: atomic :: is_always_lock_free为false时std :: atomic是否具有中断安全性?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在没有操作系统的嵌入式(ARM)环境中,如果我使用中断,那么使用std :: atomic< T>?是否存在死锁的可能性如果是这样,怎么样?

通常,任何时刻,控制都可以被中断以处理中断.特别是,如果一个人天真地拥有一个互斥体并想用它来对变量做一个“安全”,那么可以锁定它,写入和解锁,然后锁定,读取和解锁.但如果读取处于中断状态,则可以锁定,中断,锁定=>僵局.

特别是,我有一个std :: atomic< int>其中is_always_lock_free为false.我应该担心僵局吗?当我查看生成的程序集时,编写42看起来像:

bl __sync_synchronize
mov r3,#42
str r3,[sp,#4]
bl __sync_synchronize

它似乎没有锁定.用于读取值的asm是类似的.对于像交换这样的发烧友操作(可能)锁定?

解决方法

__sync_synchronize对于完整的内存屏障来说只是一个 builtin.没有涉及锁定,因此没有可能存在死锁,因为会有互斥锁和中断处理程序.

您使用的是什么ARM内核?在ARM Cortex-A7上,以下两者都适用.

#include <iostream>
#include <atomic>

int main()
{
   std::atomic<int> x;
   std::cout << std::boolalpha << x.is_lock_free() << std::endl;
   std::cout << std::atomic<int>::is_always_lock_free << std::endl;
}

我希望std :: atomic< int>没有锁的实现大多数(如果不是全部的话)在ARM上,当然从你提供的程序集中它似乎没有使用锁.

猜你在找的C&C++相关文章