利用C 11的新共享内存并发功能,两个线程可以同时分配内存.此外,由于编译器事先不知道编译的代码是否将由多个线程同时运行,因此必须假设最坏的情况.因此,我的想法是编译的代码必须
难道这不会与“你只为你使用的东西买单”的C格言形成鲜明对比吗？开销是否很小,以至于不被认为是重要的？ C内存模型的其他区域是否会减慢代码,而这些代码最终只是单线程使用？
堆管理器确实需要同步,这是多线程代码可能存在的性能问题.如有必要,可以通过该计划来减轻这种影响.标准库也在做出反应,试图获得更好的多线程分配器.编辑：关于第二段中的问题的一些想法.
即使C也需要足够安全才能使用. “YDPFWYU”很不错,但是如果你想在多线程环境中使用代码就意味着你必须在每个分配中包装一个互斥锁,那么你就会遇到很大的问题.它就像异常一样：即使是不主动使用它们的代码也应该有点意识到它可能会在它们存在的上下文中使用,程序员和编译器都需要知道这一点.编译器需要创建异常支持代码/数据结构,而程序员需要编写异常安全的代码.多线程是相同的,只是更糟糕：您编写的任何代码片段都可能在多线程环境中使用,因此您需要编写线程安全的代码,并且编译器/环境需要了解线程(放弃一些非常不安全的优化,并有一个线程安全的分配器).
这些是C中的点,就标准而言,即使您不使用的也是如此.您的特定编译器可能会为您提供一个转义窗口(禁用异常,使用单线程运行时库),但那不再是真正的C语言.
也就是说,即使(或特别是)如果你有一个全局分配器锁,单线程程序的开销也是最小的：锁只在争用时很昂贵.与其余的分配器操作相比,无争议的互斥锁定/解锁不是很重要.
在争论中,故事是不同的,这是自定义分配器可能进入的地方.
正如我上面简要提到的那样,C中的另一个地方由于存在多线程而略微放慢：禁止某些特定的优化.编译器不能在通常不具有这些访问的代码路径中发明对可能的共享变量(如全局变量或您发出指针的东西)的读取和写入(尤其是写入).这可能会减慢非常具体的代码片段,但总体而言,在程序中,您不太可能注意到.