为什么condition_variable无法MoveAssignable [英] Why is a condition_variable not MoveAssignable

问题描述

为什么condition_variable不可移动构造(根据 http://en.cppreference .com/w/cpp/thread/condition_variable )?禁止将其包含在许多可移动物体的容器中(例如std::unordered_map).

Why is a condition_variable not MoveConstructible (as per http://en.cppreference.com/w/cpp/thread/condition_variable)? That prohibits inclusion in lots of containers (eg. std::unordered_map) that move things around.

这迫使人们使用unique_ptr，这会导致额外的堆分配，而make_shared之类的东西就是要解决的.另外，如果没有池分配器，效率可能会很低.

This forces people to use a unique_ptr which incurs one extra heap allocation, which things like make_shared were built to solve. Also if one doesn't have a pool allocator this can become quite inefficient.

推荐答案

condition_variable是一个同步构造，多个线程(潜在地)同时使用. (实际上，这就是它的目的.)您如何安全地移动它?例如，假设它直接包含一个自旋锁.某个线程正在进程地址空间中的给定地址上旋转，您是否要将对象从其下面移出?

condition_variable is a synchronization construct that multiple threads are (potentially) using simultaneously. (In fact, that's its purpose.) How could you move it safely? E.g., suppose it directly contains a spinlock. Some thread is spinning on a given address in your process address space and you're going to move the object out from under it?

任何一种用户模式同步构造都无法移动.进行实际同步的操作需要固定的地址.您可以强制该对象在不会移动的已分配堆的对象上执行其所有实际工作-然后您就可以直接转到要避免的堆的间接访问. (内核模式同步结构可以移动:您已经掌握了一些操作系统的东西.但是使用使用它们要昂贵得多.)

Any kind of user-mode synchronization construct can't be moved. The thing that does the actual synchronization needs a fixed address. You could force the object to do all of its real work on a heap-allocated object that wouldn't be moved - and there you go right to the indirection to the heap that you wanted to avoid. (Kernel-mode synchronization constructs can be moved: you've got a handle to some OS thing. But they're much more expensive to use.)

它们也不能被复制-因为那意味着什么?

They can't be copied either - because what would that mean?

必须是这种方式.您的设计必须解决这个问题.

It just has to be this way. Your design must account for it, that's all.

(而且我不太理解您的问题的第二段.make_shared的目的是使引用计数便宜一些，并且与移动内容无关.池分配器可能会也可能不会改善任何特定情况，更不用说这种情况了，除非您进行测量，否则您将不会知道.)

(And I don't really understand the second paragraph of your question. make_shared was built to make ref counts less expensive and don't have anything to do with moving stuff around. A pool allocator may or may not improve any particular situation, much less this one, and you won't know unless you measure it.)

这篇关于为什么condition_variable无法MoveAssignable的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！