blocks|key|2754081|text|不，读和写不是原子的，你需要使用一些同步机制来同步它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2754082|此外，您必须将共享整数标记为易失性，否则优化器可能会认为变量永远不会在您的某个线程中更新。|2754083|gcc允许您对int、long和long+long(以及它们的无符号对等项)执行原子操作。|offset|length|style|CODE|2754084|查找以下函数：|2754085|type+__sync_fetch_and_add+(type+*ptr,+type+value);
type+__sync_fetch_and_sub+(type+*ptr,+type+value);
type+__sync_fetch_and_or+(type+*ptr,+type+value);
type+__sync_fetch_and_and+(type+*ptr,+type+value);
type+__sync_fetch_and_xor+(type+*ptr,+type+value);
type+__sync_fetch_and_nand+(type+*ptr,+type+value);|code-block|syntax|javascript|2754086|entityMap^0|0|0|0|3|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@$F|V|G|W|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|Y|8|@]|9|@]|A|$O|P]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

No the read and write are not atomic, You will need to synchronize it using some synchronization mechanism.

Also, You MUST mark the shared integer as volatile, otherwise the optimizer might think the variable is never updated in one of your threads.

<code>gcc</code> allows you to do atomic operations on int‘s, long‘s and long long‘s (and their unsigned counterparts). 

Look up for the functions: 

<pre><code>type __sync_fetch_and_add (type *ptr, type value);
type __sync_fetch_and_sub (type *ptr, type value);
type __sync_fetch_and_or (type *ptr, type value);
type __sync_fetch_and_and (type *ptr, type value);
type __sync_fetch_and_xor (type *ptr, type value);
type __sync_fetch_and_nand (type *ptr, type value);
</code></pre>

blocks|key|2754126|text|是的，您需要通过互斥、临界区、互锁访问等同步对变量的访问，以确保读取线程不会读取不完整的字节，而写入线程仍在保存它们。这在多核/CPU系统中尤其重要，在这种系统中，两个线程可以真正并行地访问变量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2754127|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|$]]

Yes, you need to synchronize access to the variable, either with a mutex, a critical section, interlocked access, etc to make sure that the reading thread does not read incomplete bytes while the writing thread is still saving them. This is especially important on multi-core/CPU systems, where the two threads can truely access the variable in parallel.

blocks|key|4369511|text|是的，您需要使用某种同步机制来保护生成器线程和读取器线程中的队列索引。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4369512|HTH|4369513|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|$]]

Yes, you need to protect the queue indexes in both the generator and the reader threads by using some kind of synchronization mechanism, like a mutex.

HTH

blocks|key|4652187|text|如果您真的只共享一个整数，那么从<atomic>头文件看，std::atomic<int>听起来像是正确的类型。(如果您使用的是旧版编译器，还应该有Boost或TR1版本。)这确保了原子读取和写入。据我所知，没有必要使用volatile限定符。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4652188|entityMap^0|G|8|T|G|32|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

If you're really just sharing one single integer, then <code>std::atomic&lt;int&gt;</code> sounds like the right type to use, from the <code>&lt;atomic&gt;</code> header. (There should also be Boost or TR1 versions if you have an old compiler.) This ensures atomic reads and writes. There's no need for a <code>volatile</code> qualifier as far as I understand.

blocks|key|2754227|text|在大多数主流架构中，对齐正确的数据的读写不超过一个机器字(通常是int解析的任何内容)都是原子的。这并不意味着每个架构都是如此。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2754228|这意味着不，您不能仅仅读取head和tail并期望数据是一致的。但是，例如，如果sizeof(int)恰好是4，sizeof(short)恰好是2，如果你不关心“非主流”平台，你可以做一些联合的把戏，而不需要原子操作或互斥锁。|2754229|如果您希望您的代码是可移植的，那么就没有办法绕过适当的锁定或原子比较/交换。|2754230|关于volatile，这确实为Microsoft+Visual+C%2B%2B插入了一个内存屏障(作为编译器特定的诡辩)，但该标准不保证任何特殊的东西，除了编译器不会优化变量。就目前而言，创建volatile并没有多大帮助，而且它也不能保证线程安全。|2754231|entityMap^0|W|3|0|D|4|I|4|14|B|1K|D|0|0|2|8|2K|8|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|L|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|M|$]]

Reads and writes of properly aligned data no larger than a machine word (usually whatever <code>int</code> resolves to) are atomic on most major architectures. That does not mean every architecture.

This means that no, you cannot just read <code>head</code> and <code>tail</code> and expect that data is consistent. However, if for example <code>sizeof(int)</code> happens to be 4 and <code>sizeof(short)</code> happens to be 2, and if you don't care about "not mainstream" platforms, you can do some union trickery and get away without atomic operations or a mutex.

If you want your code to be portable, there is no way around proper locking or atomic compare/exchange.

About <code>volatile</code>, this does insert a memory barrier for Microsoft Visual C++ (as a compiler-specific sophistry) but the standard does not guarantee anything special other than that the compiler won't optimize the variable. Insofar, making something <code>volatile</code> does not really help much, and it guarantees thread safety in no way.

blocks|key|2754270|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2754271|读/写数据时还需要使用互斥锁吗？|blockquote|2754272|2754273|2754274|是的，你需要一把锁。您可能对称为读/写锁的更具体的实现感兴趣。|2754275|您还可以使用原子和/或内存屏障。使用这些将需要更好地理解您的目标架构。重现多线程bug可能非常困难，这些替代方案应该被认为是一种可能不可移植的优化。|2754276|2754277|我见过在不同线程之间共享变量的关键字不稳定，我也需要使用它吗？|2754278|2754279|2754280|啊呀。不是的！对于C%2B%2B中的多线程读写来说，这不是一个安全或可移植的解决方案。使用原子、锁、复制、不可变和纯实现(等等)而不是。|2754281|对volatile的解释可以根据平台和/或编译器的不同而有所不同，并且在C或C%2B%2B中没有指定以任何特定的方式操作多线程读写(有一个古老的错误传说，即它可以可靠地用作原子读/写)。我曾经在一个多线程的C%2B%2B程序中测试过volatile的有效性(在一台英特尔-mac和苹果公司的gcc的电脑上)。我不会提供结果，因为它工作得足够好，一些人可能会考虑使用它，尽管他们不应该考虑使用它，因为“几乎”还不够好。|offset|length|style|CODE|2754282|为了限定volatile的使用:它存在于我的(大型的、严格编写的、支持多线程的)代码库中，唯一的目的是与平台相关的atomics接口。坦率地说:早些时候还有一些其他用途，但它们可以而且应该被删除。|2754283|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|1|8|30|8|0|4|8|0^^$0|@$1|2|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|11|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|12|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|13|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|14|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|15|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|16|7|@]|8|@]|9|$]]|$1|K|3|L|4|C|6|17|7|@]|8|@]|9|$]]|$1|M|3|-4|4|5|6|18|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|19|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|1A|7|@]|8|@]|9|$]]|$1|Q|3|R|4|5|6|1B|7|@$S|1C|T|1D|U|V]|$S|1E|T|1F|U|V]]|8|@]|9|$]]|$1|W|3|X|4|5|6|1G|7|@$S|1H|T|1I|U|V]]|8|@]|9|$]]|$1|Y|3|-4|4|5|6|1J|7|@]|8|@]|9|$]]]|Z|$]]

<blockquote>
 Do I still need to use mutex lock when reading/writing data?
</blockquote>

Yes, you will need a lock. You may be interested in a more specific implementation called a read/write lock.

You can also use atomics and/or memory barriers. Using these will require a better understanding of your target architectures. Reproducing multithreading bugs can be very difficult, and these alternatives should be considered an optimization which may not be portable.

<blockquote>
 I've seen keyword volatile around variables shared between different threads, do I need to use that too?
</blockquote>

Yikes. No! That is not a safe or portable solution to multithreaded reads and writes in C++. Use atomics, locks, copying, immutable and pure implementations (etc...) instead.

Interpretation of <code>volatile</code> can vary by platform and/or compiler, and it's not specified to operate any particular way in C or C++ for the purpose of multithreaded reads and writes (there's an old false legend that it can be used reliably as an atomic read/write). I once tested the effectiveness of <code>volatile</code> in a multithreaded C++ program for fun (on an intel-mac with apple's gcc). I won't provide the results because it worked well enough that some people might consider using it, although they should not because 'almost' isn't good enough.

And to qualify the use of <code>volatile</code>: It exists in my (large, strictly written, multithreading aware) codebase for the sole purpose of interfacing with platform dependent atomics APIs. And being entirely honest: there are a few other uses from earlier days, but they can and should be removed.

Simple edition: In a C++ program I'm using two different threads to work with some integer variable. but I'm sure one is always writing some value into it and the other one is only reading That. do I still need to use mutex lock when reading/writing data?

Now details : The main idea is that first thread generates some information and saves them into an array, and the second thread reads data from that array and process them. this array represents a queue. meaning I have two index values pointing to the first and last item in queue. Now I'm wondering if I have to lock these two index values whenever I'm reading or writing values or is it ok to check them without locking? note that generator thread is the only thread changing index of queue_back, and processor thread has exclusive permission to change queue_front.

if makes any change I'm developing for a linux based system and the code is compiled using gcc. 

PS: In some codes which use threading, I've seen keyword <code>volatile</code> around variables shared between different threads, do I need to use that too?

do need to use mutex lock?

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

简单版:在C++程序中，我使用两个不同的线程来处理某个整数变量。但我确信其中一个总是在其中写入一些值，而另一个只是在读取这些值。在读/写数据时，我还需要使用互斥锁吗？现在详细说明:主要思想是第一个线程生成一些信息并将它们保存到一个数组中，第二个线程从该数组中读取数据并处理它们。该数组表示一个队列。这意味着我有两个索引值...

问需要使用互斥锁吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问需要使用互斥锁吗？EN