是“volatile sig_atomic_t”吗？多余？ [英] Is "volatile sig_atomic_t" redundant?

问题描述

通常会看到如下声明：


静态volatile sig_atomic_t caught_signal = 0;


C99将sig_atomic_t定义为a ... ...（可能是volatile限定的）整数

类型的对象，可以作为原子实体访问，即使在异步中断存在的情况下也是如此。


这是否意味着使用易失性在上面的声明中是多少？b $ b多余？ （这对我来说肯定是这样的。）


TIA


-

===== ============================================= ===== =================

Ian Pilcher i 。******* @ comcast.net

========================== ======================== ======================

It''s pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;

C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts."

Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)

TIA

--
================================================== ======================
Ian Pilcher i.*******@comcast.net
================================================== ======================

推荐答案

Ian Pilcher写道：

Ian Pilcher wrote:

看到如下声明很常见：
<静态volatile sig_atomic_t caught_signal = 0;
C99将sig_atomic_t定义为可以作为原子访问的对象的...（可能是volatile限定的）整数类型实体，即使存在异步中断。

这是否意味着使用易失性中断。在上面的声明中是多余的？ （这听起来对我来说确实如此。）
...

It''s pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;

C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts."

Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)
...

首先，''sig_atomic_t''并不代表线程原子。 。 sig_atomic_t是

a明显较弱的保证。


其次，将对象声明为易变并不会使其成为原子。

''volatile''与原子性没有任何关系。它只是禁用

某些优化。为了确保线程原子性，程序

必须使用其他特定于平台的结构。


-

祝你好运，

Andrey Tarasevich

Firstly, ''sig_atomic_t'' doesn''t mean "thread atomic". ''sig_atomic_t'' is
a significantly weaker guarantee.

Secondly, declaring an object as ''volatile'' doesn''t make it atomic.
''volatile'' doesn''t have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich写道：

Andrey Tarasevich wrote:

首先，''sig_atomic_t''没有意思是线程原子。 ''sig_atomic_t''是一个明显较弱的保证。

其次，将一个对象声明为'volatile'并不会使它成为原子。
''volatile' 与原子性没有任何关系。它只是禁用了某些优化。为了确保线程原子性，程序必须使用其他特定于平台的结构。

Firstly, ''sig_atomic_t'' doesn''t mean "thread atomic". ''sig_atomic_t'' is
a significantly weaker guarantee.

Secondly, declaring an object as ''volatile'' doesn''t make it atomic.
''volatile'' doesn''t have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

嗯？


-

====================================== ============ ======================

Ian Pilcher i。******* @ comcast.net

========= ========================================= ========= =============

Huh?

--
================================================== ======================
Ian Pilcher i.*******@comcast.net
================================================== ======================

文章< FL ***************** ***@comcast.com> ;,

Ian Pilcher< i。******* @ comcast.net>写道：

In article <FL********************@comcast.com>,
Ian Pilcher <i.*******@comcast.net> wrote:

看到声明很常见，例如：
static volatile sig_atomic_t caught_signal = 0;
C99将sig_atomic_t定义为可以作为原子实体访问的对象类型的...（可能是volatile限定的）整数类型，即使存在异步中断也是如此。 "
这是否意味着使用易失性在上面的声明中是多余的？ （这听起来对我来说确实如此。）

It''s pretty common to see declarations such as: static volatile sig_atomic_t caught_signal = 0; C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts." Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)

volatile告诉编译器，引用之间的值可能已经改变了

，所以，例如，


a =（int）caught_signal;

b =（int）caught_signal;


不一定
a = b =（int）caught_signal;


因为两者之间可能存在信号。


sig_atomic_t即使在存在中断的情况下，处理器也可以读取一个

go。例如，如果你有
volatile volatile var;


那么在-some- processor上有可能处理器

可能会读取双倍的前4个字节，被中断并且

暂停读取中途，然后再次读取读取，

在信号覆盖了双重信号之后......剩下的是
旧值的一半和新值的一半。


本主题涉及与处理器相关的事项关于是否或

什么操作在什么条件下重新启动，这可能是受POSIX sigaction（）影响的
，并且可能会受到
$ b $的影响b非常依赖OS的例程，例如SGI的IRIX handle_sigfpes（）。但是

无论处理器如何处理这些事情，sig_atomic_t都是

你可以肯定不会因为损坏的字节而结束的事情

到期中断，缓存一致性等问题。

更有趣的是，如果你有一个元素

类似于sig_atomic_t，其中一个保证基本

算术运算，例如递增1或减少

一将不间断地完成，即使它需要一个特殊的处理器指令来执行此操作。如果你可以肯定

能够做var ++和var--没有中断，那么你可以

impliment信号量而不必进入驱动程序例程
提升高级别面具或优先级以保护交易。


注意你所说的访问：做信号量，你

必须超越只读/写到至少一个读 - 修改 - 写

原子指令。

-

哦，成为一个Blobel！

volatile tells the compiler that the value may have changed
between references, so that, for example,

a = (int) caught_signal;
b = (int) caught_signal;

is not necessarily going to be the same as

a = b = (int) caught_signal;

because there might have been a signal between the two.

sig_atomic_t is something that can be read by the processor in one
go, even in the presence of interrupts. For example, if you had

volatile double var;

then on -some- processors there is the possibility that the processor
might read the first 4 bytes of the double, get interrupted and
suspend the read half-way through, and pick up the read again later,
after the signal has overwritten the double... leaving you with
half the old value and half the new value.

This topic gets into processor dependant matters about whether or
what operations get restarted under what conditions, which can be
influenced by the POSIX sigaction(), and can be influenced by
very OS dependant routines such as SGI''s IRIX handle_sigfpes(). But
no matter how the processor handles such things, sig_atomic_t is
something that you can be sure will not end up with corrupted bytes
due to interrupts, cache coherency matters and so on.
What gets even more interesting is if you have an element
similar to sig_atomic_t in which one is guaranteed that basic
arithmetic operations such as "increment by one" or "decrement
by one" will be done without interruption, even if it requires
a special processor instruction to do so. If you can be sure
of being able to do var++ and var-- without interrupts, then you can
impliment semaphores without having to drop into a driver routine
that raises high-level masks or priorities to guard the transaction.

Notice what you quoted said "accessed": to do semaphores, you
have to go beyond just read/writes into at least one read-modify-write
atomic instruction.
--
Oh, to be a Blobel!

这篇关于是“volatile sig_atomic_t”吗？多余？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！