blocks|key|2949464|text|我不认为编译器会做这样的优化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949465|unlock(gmutex)|code-block|syntax|javascript|2949466|这是函数，编译器不能假定在解锁函数中bin指向的值是否会改变。|2949467|例如，也许bin来自一个globe。因此，bin的优化不能跨越函数调用。|2949468|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I don't think compiler will do such kind of optimization.

<pre><code>unlock(gmutex)
</code></pre>

this is function, the compiler can't assume that value pointed by bin will be changed in unlock function or not. 

for example, maybe bin comes from a globe. So optimization for bin can't cross the function call.

blocks|key|2949480|text|您的示例不必要地复杂，因为您通过与声明的类型不同的类型读取bin。别名规则相当复杂，char甚至很特别，我不会对此发表评论。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2949481|假设您的声明为int*+bin+(因此您不必强制转换指针)，编译器将无权在函数调用之间对语句进行重新排序，它们形成了所谓的序列点。在调用unlock之前和之后，*bin的值可能不同，因此它必须在调用之后加载值。|2949482|编辑:正如slartibartfast所指出的，对于这个参数，unlock必须是(或包含)函数调用，而不仅仅是一个由编译器解析成一系列操作的宏。|2949483|entityMap^0|T|3|16|4|0|7|8|1W|6|28|4|0|V|6|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$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]]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|K|$]]

Your example is unnecessarily complicated because you are reading <code>bin</code> through a different type than it is declared. Aliasing rules are quite complicated, <code>char</code> is even special, I wouldn't comment on that.

Supposing your declaration would be <code>int* bin</code> (and so you wouldn't have to cast the pointer) a compiler would not have the right to reorder statements across function calls, they form so-called sequence points. The value of <code>*bin</code> before and after the call to <code>unlock</code> could be different, so it has to load the value after the call.

Edit: as noted by slartibartfast, for this argument it is essential that <code>unlock</code> is (or contains) a function call and isn't just a macro that resolves to a sequence of operations by the compiler.

blocks|key|5766271|text|正如我在直接回答中所说的:你的互斥体不会保护任何东西。*bin所指向的char数组可能会在int访问期间被修改，因此根据您的机器的不同，您甚至不会得到关于您想要访问的内存的一致视图。回到你的问题:编译器不会将源代码转换成你所设想的序列，但它很可能会产生机器语言，这种语言实际上会以你的源代码的方式运行。如果它能够检查函数lock、unlock和sleep+(看起来像是宏)，并且可以推断出对所涉及的内存位置没有副作用，并且对调用sleep()没有实现定义的含义，这将使临时(“缓存”，尽管标准不使用这个术语)值无效，那么它就有权生成一个像您给出的指令序列。C(直到C99)本质上是单线程的，编译器可以采用它想要的任何优化策略，只要代码的行为“就像”它将在理想的假设的C机器上运行一样。Jens提到的序列点在单线程条件下不会影响正确性:编译器可以在整个函数期间将foo放在寄存器中，甚至可以使用*bin指向的内存位置作为foo.i的别名，所以这段代码本质上是危险的(尽管我认为它不会在大多数编译器上表现出这种行为)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5766272|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|$]]

As I said in the direct reply: your mutex isn't protecting anything IMHO. The char array which *bin points into can get modified during the int-access so depending on your machine you won't even get a consistent view on the memory you wanted to access. 
Back to your question: a compiler will not transform the source code to the sequence which you envisioned BUT it may very well produce machine language which in effect will behave the way your source code does. If it is able to inspect the functions lock, unlock and sleep (which seem to be macros anyway) and can deduce that there is no side effect to the involved memory locations AND there is no implementation defined meaning to calls to e.g. sleep() which would render temporary ("cached" although the standard doesn't use this term) values invalid then it is entitled to produce an instruction sequence like the one you gave. C (up to C99) is inherently single-threaded and the compiler can employ any optimization strategy it wants as long as the code behaves "as if" it would run on the ideal hypothetical C machine. The sequence points which Jens mentioned don't affect the correctness under single threaded conditions: the compiler could hold foo in a register during the whole function or it could even alias foo.i with the memory location pointed to by *bin, so this code is inherently dangerous (alhtough I think it will not exhibit this behaviour on most compilers).

I have a question regarding optimizations the compiler can potentially do.

The below code will speak for itself (this is an example):

<pre><code>typedef struct test
{
 short i;
} s_test;

int function1(char *bin)
{
 s_test foo;

 lock(gmutex);
 foo.i = *(int*)bin * 8;
 unlock(gmutex);

 sleep(5);
 //
 // Here anything can happen to *bin in another thread
 // an inline example here could be: *(volatile int *)bin = 42;
 //

 int b = foo.i + sizeof(char*);

 return (b &gt; 1000);
}
</code></pre>

Could the compiler ever replace the last lines with

<pre><code>return ((*(int*)bin * 8 + sizeof(char*)) &gt; 1000);
</code></pre>

It did not seem to be the case using -O2 or -O3 with gcc 4.4 but could it be the case with other compilers and with other compilation flags?

Compiler Optimization, Thread Safe?

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我有一个关于编译器可能做的优化的问题。下面的代码将说明问题(这是一个示例)：typedef struct  test{  short i;}               s_test;int function1(char *bin){  s_test foo;  lock(gmutex);  foo.i = *(int...

问编译器优化，线程安全？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编译器优化，线程安全？EN