簡體   English   中英

CPP:這是關於線程安全 FIFIO 消息隊列的 go 的合理方法嗎

[英]CPP: Is this a reasonable way to go about thread safe FIFIO message queues

請保持溫和 - 我第一次在這里發帖。 目前正在自學C++。 想玩線程並在它們之間傳遞任何類型的消息。 還沒有進入線程部分 - 只是處理消息隊列元素。 下面是我放在一起的代碼 - 至少在一個 main() 線程中。 在我開始創建自定義數據對象和線程函數之前——我想就我到目前為止所做的事情是否可行(如果不完全符合約定/標准或完全有效)達成共識——所以如果這是真的只是在尋找方向稍后將使用線程創建不必要的復雜性。

所以兩個代碼文件:

messageQueue.h包括實現以及 header 無法讓 linker 與位於單獨 cpp 文件中的實現一起工作。

#pragma once
#include<queue>         // for queue
#include<thread>        // for smart pointers
#include<mutex>         // for locking of the queue when doing push(), front() and pop()



/*
Purpose:
To provide a thread safe method of of passing messages between threads in a FIFO queue manner.
Currently this uses unique_ptr which enables a one to one publisher/consumer application, if
we need one to many publisher/consumer model then will need to investigate maintaining a collection 
of subscribers (consumers) and use shared_ptr.
Usage notes:
Message objects need to be created using make_unique not using new - e.g.
    auto messagePtr = std::make_unique<message_t<std::string>>("this is a message");
Call this way: 
    messageQueue<objectType> messageQueueName;
    messageQueueName.publish(std::move(messagePtr));
    messagePtr = messageQueueName.consume();
*/

template<class T>
class message_t
{
public:
    message_t(T message) : m_message{ message } {}

private:
    T m_message;
};

template<class T>
class messageQueue
{
public:
    messageQueue() {};
    void publish(std::unique_ptr<message_t<T>> messagePtr);
    std::unique_ptr<message_t<T>> consume();
    bool hasData();
private:
    std::queue < std::unique_ptr<message_t<T>>> m_queue;
    std::mutex m_mutex;

};

// Had to add the implementation into the header file as templated classes have link issues when in separate cpp files :-(

template<class T>
void messageQueue<T>::publish(std::unique_ptr<message_t<T>> messagePtr) {
    std::lock_guard<std::mutex> lock(m_mutex); 
    m_queue.push(std::move(messagePtr));
};

template<class T>
std::unique_ptr<message_t<T>> messageQueue<T>::consume() {
    std::unique_ptr<message_t<T>> retVal;
    {
        std::lock_guard<std::mutex> lock(m_mutex);
        if (!m_queue.empty()) { retVal = std::move(m_queue.front()); }
        m_queue.pop();
    }

    return retVal;
};

template<class T>
bool messageQueue<T>::hasData() {
    std::lock_guard<std::mutex> lock(m_mutex);
    return(!m_queue.empty());
};

main.cpp - 里面只有一個非常簡單的測試用例。

#include "messageQueue.h"
#include<string>
#include<iostream>


int main(void) {
    messageQueue<std::string> textQueue;                        // Create the message queue 
    auto messagePtr = std::make_unique<message_t<std::string>>("this is a message");    // Create a message and get its unique pointer
    std::cout << "messagePtr= " << messagePtr << std::endl;     // output the pointer value
    textQueue.publish(std::move(messagePtr));                   // Push the message pointer onto the queue : messagePtr is now 0
    auto newMessagePtr = std::make_unique<message_t<std::string>>("this is another message");   // Create a second message and get its unique pointer
    std::cout << "newMessagePtr= " << newMessagePtr << std::endl;   // output the new message pointer value
    std::cout << "Consuming messagePtr into newMessagePtr" << std::endl;    //comment
    if (textQueue.hasData()) { newMessagePtr = textQueue.consume(); }   // Pull the original pointer off the queue and assign to new message pointer
    std::cout << "newMessagePtr= " << newMessagePtr << std::endl;   // output the pointer in the new message pointer - should be first pointer value


    return(0);
}

我看到的一個問題是,如果消息隊列為空,您仍然會從中彈出。

還有一個概念性問題:在多線程環境中, hasData()永遠沒有意義。 無論它返回什么,它都可能立即被另一個線程無效。 因此,除非您接受其正確性的不確定性,否則任何代碼都不能真正依賴於返回值。

更常見的方法是簡單地try_consume無條件地使用該值(如果沒有消息則返回 nullptr )-您基本上已經將其實現為consume

另一種方法是使用阻塞consume ,它會暫停當前線程,直到其他線程寫入隊列。 然而,這需要使用信號,例如通過std::condition_variable或 atomics。 這有其陷阱,但如果您正在學習,值得花時間了解它的工作原理。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM