new和delete处理多线程问题
我正在读一本书 高效 C++：性能编程技术 作者说以下关于全局新建和删除运算符：
它们在进程上下文中管理内存，并且由于进程可能 生成多个线程，
new()和delete()必须能够在 多线程环境。另外，内存请求的大小 一个请求与下一个请求可能会有所不同。
第 6 章：单线程内存池。
这是真的吗？我认为C++没有多线程环境的概念，程序员需要通过使用某种互斥手段来处理。
I am reading a book Efficient C++: Performance Programming Techniques Authors is saying following regarding global new and delete operators:
They manage memory in the process context, and since a process may
spawn multiple threads,new()anddelete()must be able to operate in
a multithreaded environment. In addition, the size of memory requests
may vary from one request to the next.
in Chapter 6. Single-Threaded Memory Pooling.
Is this true? I thought C++ does not have a notion of a Multi-threading environment, programmer need to handle is by using some means of mutual exclusion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这将取决于实施情况。例如，Visual C++运行时在早期版本中同时具有单线程和多线程版本的堆，但从Visual C++ 2005开始它只有多线程版本。 这篇 MSDN 文章 有一个很好的内容汇总表。
当使用多线程堆时，对内存分配和释放的调用是线程安全的，但会产生额外的开销。
It will depend on implementation. For example, Visual C++ runtime had both a single-threaded and a multithreaded version of heap in earlier version, but starting with Visual C++ 2005 it only has a multithreaded version. This MSDN article has a nice summary table.
When a multithreaded heap is used calls to memory allocation and deallocation are thread-safe at expense of additional overhead.
C++（C++03标准）没有谈论多线程。然而，大多数平台都支持线程安全的
new/malloc。这是上一篇文章讨论同类的问题。在C++11中，引入了线程。
C++ (C++03 standard) doesn't talk about multi-threading. However most of the platforms support thread-safe
new/malloc. Here is a previous post discussing same kind of question.In C++11, the threads are introduced.
从 C++11（具有数据竞争的概念）开始，该标准保证
new/delete、calloc/malloc/realloc/free将在单个总订单。从 n3690 18.6.1.4 开始：
我在标准的早期版本中找不到任何此类保证，但是（就像其他人所说的那样）我相信大多数实现都为内存分配提供多线程支持。
As of C++11 (which has the concept of a data race) the standard guarantees that
new/delete,calloc/malloc/realloc/freewill occur in a single total order.From n3690 18.6.1.4:
I could not find any such guarantees in previous versions of the standard, but (like others have said) I believe most implementations provide multi-threading support for memory allocation.