等待条件的非线程替代方案。 (编辑:前摄器模式与 boost.asio?)

发布于 2024-11-02 17:20:18 字数 1867 浏览 1 评论 0原文

我正在实现一个消息传递算法。当相邻节点在节点上有足够的信息来组成消息(从相邻节点传递到该节点的信息)时,消息就会在相邻节点之间传递。如果我将每个消息设为一个线程并使用 boost::condition 使线程进入睡眠状态,直到所需的信息可用,那么实现就很简单了。

不幸的是 - 我在图中有 100k 个节点,这意味着 300k 个线程。当我询问如何创建那么多线程时,答案是我不应该 - 而是重新设计。

我的问题是:是否有等待条件的标准设计模式? 也许某种异步控制模式?

编辑:我想我可以用 proacator 模式来做到这一点。 我已编辑标签以包含 boost::asio - 看看是否有人对此有建议。

因此讨论可以是具体的,以下是到目前为止消息的定义方式:

class
Message
{
public:      
  Message(const Node* from, Node* to)
    : m_from(from), m_to(to)
  {}
  void
  operator()()
  {
    m_to->ReceiveMessage( m_from->ComposeMessage() );
  }
private:
  Node *m_from, *m_to;
};

这些消息函子当前是通过 boost::thread 启动的。然后我们有

class Node
{
    Node(Node* Neighbour1, Node* Neighbour2, Node* Neighbour3); 
   // The messages (currently threads) are created on construction, 
   // The condition locks then sort out when they actually get passed 
   // without me having to think too hard.

    void ReceiveMessage(const Message&); 
    //set m_message from received messages;
    //EDIT This looks like an async write - use boost asio here?

    Message 
    ComposeMessage()
    {
      // If possible I want to implement this function without threads
      // It works great but it if every message is a thread 
      // then I have 300k threads.
      // EDIT: this looks like an async read (use boost asio here?)

      boost::mutex::scoped_lock lock(m_mutex);
       while (!m_message) //lock the thread until parameter is set.
        m_cond.wait(lock);
      return *m_message;
   }
  private:
    boost::optional<Message> m_message;
    boost::mutex m_mutex;
    boost::condition m_cond;
}

我喜欢代码的透明度,如果可能的话希望通过条件锁的替代方案来保持相同的接口?

I am implementing a message passing algorithm. Messages pass between adjacent nodes when they have enough information at the node to compose the message - information that is passed to the node from neighbouring nodes. The implementation is trivial if I make each of messages a thread and use boost::condition to put the thread to sleep until the required information is available.

Unfortunately - I have 100k nodes in the graph which would mean 300k threads. When I asked how to make that many threads the answer was that I shouldn't - and re-design instead.

My question is: is there a standard design pattern for waiting for a condition?
Perhaps some asynchronous control pattern?

EDIT: I think I can do this with the proacator pattern.
I have edited to tags to include boost::asio - to see if anyone has suggestions with this.

So the discussion can be concrete, here is how the messages are defined so far:

class
Message
{
public:      
  Message(const Node* from, Node* to)
    : m_from(from), m_to(to)
  {}
  void
  operator()()
  {
    m_to->ReceiveMessage( m_from->ComposeMessage() );
  }
private:
  Node *m_from, *m_to;
};

These message functors are currently launched with boost::thread. Then we have

class Node
{
    Node(Node* Neighbour1, Node* Neighbour2, Node* Neighbour3); 
   // The messages (currently threads) are created on construction, 
   // The condition locks then sort out when they actually get passed 
   // without me having to think too hard.

    void ReceiveMessage(const Message&); 
    //set m_message from received messages;
    //EDIT This looks like an async write - use boost asio here?

    Message 
    ComposeMessage()
    {
      // If possible I want to implement this function without threads
      // It works great but it if every message is a thread 
      // then I have 300k threads.
      // EDIT: this looks like an async read (use boost asio here?)

      boost::mutex::scoped_lock lock(m_mutex);
       while (!m_message) //lock the thread until parameter is set.
        m_cond.wait(lock);
      return *m_message;
   }
  private:
    boost::optional<Message> m_message;
    boost::mutex m_mutex;
    boost::condition m_cond;
}

I like the transparency of the code and if possible would like to keep the same interfaces by having some alternative to the conditional lock?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

情徒 2024-11-09 17:20:18

我想您正在寻找的是反应器模式。这是大多数活动不需要太多时间的地方,并且他们正在执行合作性多任务处理。请参阅 node.js 了解该想法的 JavaScript 实现,但在 C++ 中 ACE 库 提供了这个开箱即用的概念,允许基于系统中核心数量的多个线程。

这些库都依赖于一些支持磁盘、网络等上非阻塞 IO 的操作系统 API。当您不等待操作系统,而是等待应用程序中的另一个消息源时,它们会为您提供相应的工具。

I guess what you are looking for is the reactor pattern. This is where most of the activities do not take too much time and they are doing co-operative multitasking. See node.js for a JavaScript implementation of the idea, but in C++ the ACE library provides this concept out-of-the-box allowing multiple threads based on the number of cores in the system.

These libraries all depend on some OS APIs that support non-blocking IO on disks, network, etc. When you are not waiting for the OS, but another message source in your app, they provide you with the tools for that.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文