我有一个基于循环缓冲区的无锁多生产者、单消费者队列。到目前为止，它只有非阻塞push_back() and pop_front()来电。现在我想添加这些调用的阻塞版本，但我想尽量减少这对使用非阻塞版本的代码性能的影响 - 也就是说，它不应该将它们变成“默认锁定" calls.
例如。阻塞push_back()的最简单版本如下所示：
void push_back_Blocking(const T& pkg) {
if (!push_back(pkg)) {
unique_lock<mutex> ul(mux);
while (!push_back(pkg)) {
cv_notFull.wait(ul);
}
}
}
但不幸的是，这还需要将以下块放在“非阻塞”的末尾pop_front():
{
std::lock_guard<mutex> lg(mux);
cv_notFull.notify_all();
}
虽然notify单独使用几乎不会对性能产生任何影响（如果没有线程在等待），但锁却有。
所以我的问题是：
我如何（如果可能的话使用标准 c++14）添加阻塞push_back and pop_front我的队列的成员函数不会严重影响非阻塞对应项的性能（阅读：最小化系统调用）？至少只要没有线程实际被阻塞——但理想情况下也是如此。
作为参考，我当前的版本看起来与此类似（我省略了调试检查、数据对齐和显式内存排序）：
template<class T, size_t N>
class MPSC_queue {
using INDEX_TYPE = unsigned long;
struct Idx {
INDEX_TYPE idx;
INDEX_TYPE version_cnt;
};
enum class SlotState {
EMPTY,
FILLED
};
struct Slot {
Slot() = default;
std::atomic<SlotState> state= SlotState::EMPTY;
T data{};
};
struct Buffer_t {
std::array<Slot, N> data{};
Buffer_t() {
data.fill(Slot{ SlotState::EMPTY, T{} });
}
Slot& operator[](Idx idx) {
return this->operator[](idx.idx);
}
Slot& operator[](INDEX_TYPE idx) {
return data[idx];
}
};
Buffer_t buffer;
std::atomic<Idx> head{};
std::atomic<INDEX_TYPE> tail=0;
INDEX_TYPE next(INDEX_TYPE old) { return (old + 1) % N; }
Idx next(Idx old) {
old.idx = next(old.idx);
old.version_cnt++;
return old;
}
public:
bool push_back(const T& val) {
auto tHead = head.load();
Idx wrtIdx;
do {
wrtIdx = next(tHead);
if (wrtIdx.idx == tail) {
return false;
}
} while (!head.compare_exchange_strong(tHead, wrtIdx));
buffer[wrtIdx].data = val;
buffer[wrtIdx].state = SlotState::FILLED;
return true;
}
bool pop_front(T& val) {
auto rIdx = next(tail);
if (buffer[rIdx].state != SlotState::FILLED) {
return false;
}
val = buffer[rIdx].data;
buffer[rIdx].state = SlotState::EMPTY;
tail = rIdx;
return true;
}
};
相关问题：
我专门问了一个类似的问题，关于优化使用condition_variable::notify here https://stackoverflow.com/questions/32577466/use-condition-variable-notify-without-loacking-mutex?noredirect=1#comment53010530_32577466，但是这个问题被关闭了，因为据说是重复的这个问题 https://stackoverflow.com/questions/2763714/why-do-pthreads-condition-variable-functions-require-a-mutex%99%20condition%20variable%20functions%20require%20a%20mutex?.
我不同意，因为这个问题是关于为什么一般条件变量需要互斥锁（或者更确切地说它是 pthread 等效项） - 重点是condition_variable::wait- 而不是是否/如何避免notify部分。但显然我没有说得足够清楚（或者人们只是不同意我的观点）。
无论如何，链接问题中的答案对我没有帮助，因为这有点像XY-问题 https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem无论如何，我决定就我遇到的实际问题提出另一个问题，从而允许更广泛的可能解决方案（也许有一种方法可以完全避免条件变量）。
这个问题 https://stackoverflow.com/questions/6089917/how-to-achieve-lock-free-but-blocking-behavior也很相似，但是
- 这是关于 Linux 上的 C 的内容，答案使用特定于平台的内容
构造（pthreads 和 futexes）
- 那里的作者要求高效的阻塞调用，但根本没有非阻塞调用。另一方面，我不太关心阻塞效率，但希望保持非阻塞尽可能快。
