blocks|key|354094|text|不，在C中递增的值不能保证是原子的。您需要提供同步，或者使用特定于系统的库来执行原子递增/递减。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|354095|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No, incrementing values in C is not guaranteed to be atomic. You need to provide synchronization, or use a system-specific library to perform atomic increments/decrements.

blocks|key|354129|text|正如您所记录的，它不是原子的。但在不严格的意义上，它仍然可以是“线程安全”的：long不能处于不一致的状态。这里的危险程度是，如果n线程调用vTaskSuspendAll，那么uxSchedulerSuspended将递增1到n之间的任何值。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|354130|但是，如果变量不需要是完美的，比如跟踪用户请求暂停的次数，那么这可能是非常好的。有“线程安全”的意思是“这个操作产生相同的结果，不管它的调用是如何交错的”，还有“线程安全”的意思是“如果你从多个线程调用它，没有什么会爆炸”。|354131|entityMap^0|13|4|1T|1|1Y|F|2G|K|35|1|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|I|$]]

It's not atomic, as you've documented. But it could still be "thread safe" in a less strict sense: a <code>long</code> can't be in an inconsistent state. The extent of the danger here is that if <code>n</code> threads call <code>vTaskSuspendAll</code> then <code>uxSchedulerSuspended</code> will be incremented by anywhere between 1 and <code>n</code>.

But this could be perfectly fine if the variable is something that doesn't need to be perfect, like a tracker for how many times the user asked to suspend. There's "thread safe" meaning "this operation produces the same result, no matter how its calls are interleaved" and there's "thread safe" meaning "nothing explodes if you call this from multiple threads".

blocks|key|136348|text|这个操作不是原子的，但它并没有说它是原子的。然而，代码是线程安全的，但您必须非常熟悉代码正在做什么，以及它如何适应调度器的设计才能知道这一点。如果其他任务在加载和存储之间修改变量，这并不重要，因为当执行任务下一次运行时，它将发现变量处于与执行原始加载时相同的状态(因此修改和写入部分仍然是一致和有效的)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|136349|正如之前发布的说明，long不能处于不一致的状态，因为它是运行它的架构的基本类型。但是，考虑如果代码在8位(或16位)机器上运行，而变量是32位，会发生什么情况。那么它将不是线程安全的，因为完整的32位将被一次修改字节或字，而不是一次全部修改。在这种情况下，当发生上下文切换时，可能会将一个字节加载到寄存器中，进行修改，然后写回RAM+(其他三个字节保持不变)。如果下一个执行的任务读取相同的变量，它将读取一个已修改的字节和三个未修改的字节-这就有了一个大问题。|136350|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The operation is not atomic, but nowhere does it say it is. However, the code is thread safe, but you would have to be very familiar with what the code was doing, and how it fitted into the design of the scheduler to know that. It does not matter if other tasks modify the variable between the load and store because when the executing task next runs it will find the variable in the same state as when the original load was performed (so the modify and write portions are still consistent and valid).

As a previous posted notes, the long cannot be in an inconsistent state because it is the base type of the architecture on which it is running. Consider however what would happen if the code was running on an 8 bit machine (or 16 bit) and the variable was 32 bit. Then it would not be thread safe because the full 32 bits would be modified byte or word at a time, rather than all at once. In that scenario, one byte might be loaded into a register, modified, then written back to RAM (leaving the other three bytes unmodified) when a context switch occurs. If the next task that executed read the same variable it would read one byte that had been modified and three bytes that had not - and you have a major problem.

I found some code in FreeRTOS (FreeRTOSV7.4.0\FreeRTOS\Source\tasks.c):

<pre><code>void vTaskSuspendAll( void )
{
 /* A critical section is not required as the variable is of type
 portBASE_TYPE. */
 ++uxSchedulerSuspended;
}
</code></pre>

It is explicitly said no need to protect due to the type is "portBASE_TYPE", which is a "long" type. My understood is that it assumes the self-increment to this type is atomic. But after I disassembled it I could not find any proof, its a plain load->add->store. Then is it a problem?

<pre><code>void vTaskSuspendAll( void )
{
 /* A critical section is not required as the variable is of type
 portBASE_TYPE. */
 ++uxSchedulerSuspended;
 4dc: 4b03 ldr r3, [pc, #12] ; (4ec &lt;vTaskSuspendAll+0x10&gt;)
 4de: f8d3 2118 ldr.w r2, [r3, #280] ; 0x118
 4e2: 1c50 adds r0, r2, #1
 4e4: f8c3 0118 str.w r0, [r3, #280] ; 0x118
 4e8: 4770 bx lr
 4ea: bf00 nop
 4ec: 00000000 .word 0x00000000

000004f0 &lt;xTaskGetTickCount&gt;:
 return xAlreadyYielded;
}
</code></pre>

Is self increment in C thread safe?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在FreeRTOS (FreeRTOSV7.4.0\FreeRTOS\Source\tasks.c)中找到了一些代码：void vTaskSuspendAll( void ){    /* A critical section is not required as the variable is of type   ...

问C线程中的自我增量是安全的吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C线程中的自我增量是安全的吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C线程中的自我增量是安全的吗？
EN