이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 6. Multithreading


AMQ C++ supports full multithreading with C++11 and later. Limited multithreading is possible with older versions of C++. See Section 6.5, “Using Older Versions of C++”.

6.1. Threading Model

The container object can handle multiple connections concurrently. As AMQP events occur on connections, the container calls messaging_handler callback functions. Callbacks for any one connection are serialized (not called concurrently), but callbacks for different connections can be safely executed in parallel.

You can assign a handler to a connection in container::connect() or listen_handler::on_accept() using the handler connection option. We recommend creating a separate handler for each connection. That way the handler does not need locks or other synchronization to protect it against concurrent use by library threads. If any non-library threads use the handler concurrently, then you will need synchronization.

6.2. Thread-Safety Rules

The connection, session, sender, receiver, tracker, and delivery objects are not thread-safe and are subject to the following rules.

  1. You must use them only from a messaging_handler callback or a work_queue function.
  2. You must not use objects belonging to one connection from a callback for another connection.
  3. You can store AMQ C++ objects in member variables for use in a later callback, provided you respect rule two.

The message object is a value type with the same threading constraints as a standard C++ built-in type. It cannot be concurrently modified.

6.3. Work Queues

The work_queue interface provides a safe way to communicate between different connection handlers or between non-library threads and connection handlers.

  • Each connection has an associated work_queue.
  • The work queue is thread-safe (C++11 or greater). Any thread can add work.
  • A work item is a std::function, and bound arguments are called like an event callback.

When the library calls the work function, it will be serialized safely so that you can treat the work function like an event callback and safely access the handler and AMQ C++ objects stored on it.

6.4. The Wake Primitive

The connection::wake() method allows any thread to prompt activity on a connection by triggering an on_connection_wake() callback. This is the only thread-safe method on connection.

wake() is a lightweight, low-level primitive for signaling between threads.

  • It does not carry any code or data, unlike work_queue.
  • Multiple calls to wake() might be coalesced into a single on_connection_wake().
  • Calls to on_connection_wake() can occur without any application call to wake() since the library uses wake() internally.

The semantics of wake() are similar to std::condition_variable::notify_one(). There will be a wakeup, but there must be some shared application state to determine why the wakeup occurred and what, if anything, to do about it.

Work queues are easier to use in many instances, but wake() may be useful if you already have your own external thread-safe queues and need an efficient way to wake a connection to check them for data.

6.5. Using Older Versions of C++

Before C++11 there was no standard support for threading in C++. You can use AMQ C++ with threads but with the following limitations.

  • The container will not create threads. It will only use the single thread that calls container::run().
  • None of the AMQ C++ library classes are thread-safe, including container and work_queue. You need an external lock to use container in multiple threads. The only exception is connection::wake(). It is thread-safe even in older C++.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat