Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation Request: Thread Safety Guarantees for Publisher APIs #2417

Open
owny990312 opened this issue Feb 6, 2025 · 4 comments
Open
Labels
question Further information is requested

Comments

@owny990312
Copy link

I'm using the iceoryx publisher APIs and have questions about their thread safety guarantees. Specifically:

Current Situation

In UntypedPublisherImpl, there are three core APIs:

  • loan()
  • publish()
  • release()

However, I couldn't find clear documentation about their thread safety guarantees.

Questions

  1. Are these APIs thread-safe in UntypedPublisherImpl?

    • Can multiple threads safely call loan() concurrently?
    • Can multiple threads safely call publish() on different chunks concurrently?
    • Can multiple threads safely call release() on different chunks concurrently?
  2. Do these thread safety guarantees (if any) apply to all publisher types in iceoryx?

    • TypedPublisher
    • PublisherImpl
    • Other publisher implementations
  3. If these APIs are thread-safe:

    • What synchronization mechanism is used internally?
    • Are there any performance implications users should be aware of?
    • Are there any usage patterns we should avoid?

Request

Could you please:

  1. Clarify the thread safety guarantees for these APIs
  2. Update the documentation to explicitly state thread safety guarantees
  3. Provide examples of correct multi-threaded usage if applicable

This information would be very helpful for users implementing multi-threaded publishers in their applications.

Additional Context

  • Currently using iceoryx version: 2.0.6
  • Use case: Multiple threads publishing data through the same publisher instance
@elfenpiff
Copy link
Contributor

elfenpiff commented Feb 6, 2025

@owny990312 By default, all classes are not threadsafe unless it is explicitly stated in the documentation. You should also avoid moving classes between threads.

So the UntypedPublisher, Publisher, Subscriber and UntypedSubscriber are all not threadsafe.
Furthermore, you should never move a loaned sample from the Publisher or a received sample from the Subscriber into another thread!

So this is not allowed in iceoryx:

// publisher
auto sample = publisher.loan().expect("loaned sample successfully");

// forbidden, since the sample access under the hood the publisher which is not threadsafe
std::thread my_thread([sample = std::move(sample)](){
   *sample = 123;
});

The same applies to the subscriber.

@mossmaurice mossmaurice added the question Further information is requested label Feb 6, 2025
@owny990312
Copy link
Author

@owny990312 By default, all classes are not threadsafe unless it is explicitly stated in the documentation. You should also avoid moving classes between threads.默认情况下,除非文档中明确指出,否则所有类都不是线程安全的。你也应该避免在不同线程之间移动类。

So the UntypedPublisher, Publisher, Subscriber and UntypedSubscriber are all not threadsafe.所以 UntypedPublisher, Publisher, SubscriberUntypedSubscriber 都不是线程安全的。 Furthermore, you should never move a loaned sample from the Publisher or a received sample from the Subscriber into another thread!此外,你绝不能将从发布者借来的样品或从接收者收到的样品移到另一个线程中!

So this is not allowed in iceoryx:所以在 iceoryx 中不允许这样做:

// publisher
auto sample = publisher.loan().expect("loaned sample successfully");

// forbidden, since the sample access under the hood the publisher which is not threadsafe
std::thread my_thread(sample = std::move(sample){
*sample = 123;
});
The same applies to the subscriber.同样的规定也适用于订阅者。

Thanks for your reply.

When there are two subscribers (either in different processes or threads) subscribing to the same topic, and both are waiting for data from the same publisher, if we use subscriber->release(), could this scenario occur: after the first subscriber receives and releases the data, the second subscriber might get empty or invalid data, potentially leading to undefined behavior?

Image

@elfenpiff
Copy link
Contributor

@owny990312

When there are two subscribers (either in different processes or threads) subscribing to the same topic, and both are waiting for data from the same publisher, if we use subscriber->release(), could this scenario occur: after the first subscriber receives and releases the data, the second subscriber might get empty or invalid data, potentially leading to undefined behavior?

No, two different subscribers do not cause any problems. If every subscriber is used correctly, you can have arbitrarily many subscribers in arbitrarily many threads and do whatever you want with them.

@owny990312
Copy link
Author

@owny990312

When there are two subscribers (either in different processes or threads) subscribing to the same topic, and both are waiting for data from the same publisher, if we use subscriber->release(), could this scenario occur: after the first subscriber receives and releases the data, the second subscriber might get empty or invalid data, potentially leading to undefined behavior?当有两个订阅者(分别在不同的进程或线程中)订阅同一个主题,并且两个订阅者都从同一个发布者等待数据时,如果我们使用 subscriber->release(),这种情况是否可能发生:在第一个订阅者接收到并释放数据之后,第二个订阅者可能会收到空数据或无效数据,从而可能导致未定义的行为?

No, two different subscribers do not cause any problems. If every subscriber is used correctly, you can have arbitrarily many subscribers in arbitrarily many threads and do whatever you want with them.不,两个不同的订阅者不会引起任何问题。如果每个订阅者都使用正确,你可以在任意多个线程中拥有任意多个订阅者,并且可以随心所欲地使用它们。

Thanks for your reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants