Thread Safety Analysis of Shared Memory APIs

[owny990312]

Describe the feature

Describe the feature
The question concerns the thread safety of shared memory interface APIs, specifically:

z_shm_provider_garbage_collect
z_shm_provider_defragment
z_shm_provider_alloc
z_publisher_put
In a multi-threaded environment where multiple publishers with the same topic are publishing data, are these APIs thread safe?

[yellowhatter]

Hello, @owny990312 !
This is a tricky question.
The thread safety of shm provider and allocation layout API's depend on provider's backend. If the backend is thread-safe, the whole provider with all it's API will also be thread-safe.
Our general-purpose PosixShmProviderBackend is thread-safe.
If you are using your own C-callback-based backend implementation, the thread-safety will depend on it

SHM Api is marked unstable and thus we are still polishing it. Your question raises a good point to improve, thank you

[owny990312]

Hello, @owny990312 ! This is a tricky question.这是一个棘手的问题。 The thread safety of shm provider and allocation layout API's depend on provider's backend. If the backend is thread-safe, the whole provider with all it's API will also be thread-safe.shm 提供者和分配布局 API 的线程安全性取决于提供者的后端。如果后端是线程安全的，那么整个提供者及其所有 API 也将是线程安全的。 Our general-purpose PosixShmProviderBackend is thread-safe.我们的通用 PosixShmProviderBackend 是线程安全的。 If you are using your own C-callback-based backend implementation, the thread-safety will depend on it如果你使用的是自己的基于 C 回调的后端实现，线程安全性将取决于它

SHM Api is marked unstable and thus we are still polishing it. Your question raises a good point to improve, thank youSHM Api 标记为不稳定，因此我们仍在对其进行完善。您的问题提出了一个很好的改进点，谢谢。

Thanls for your reply.

How to set its provider's backend, if we use

    z_posix_shm_provider_new(&shm_provider_, z_loan(shm_layout_));

it means we set general-purpose PosixShmProviderBackend ?

[yellowhatter]

Hello, @owny990312 ! This is a tricky question.这是一个棘手的问题。 The thread safety of shm provider and allocation layout API's depend on provider's backend. If the backend is thread-safe, the whole provider with all it's API will also be thread-safe.shm 提供者和分配布局 API 的线程安全性取决于提供者的后端。如果后端是线程安全的，那么整个提供者及其所有 API 也将是线程安全的。 Our general-purpose PosixShmProviderBackend is thread-safe.我们的通用 PosixShmProviderBackend 是线程安全的。 If you are using your own C-callback-based backend implementation, the thread-safety will depend on it如果你使用的是自己的基于 C 回调的后端实现，线程安全性将取决于它
SHM Api is marked unstable and thus we are still polishing it. Your question raises a good point to improve, thank youSHM Api 标记为不稳定，因此我们仍在对其进行完善。您的问题提出了一个很好的改进点，谢谢。

Thanls for your reply.

How to set its provider's backend, if we use

    z_posix_shm_provider_new(&shm_provider_, z_loan(shm_layout_));

it means we set general-purpose PosixShmProviderBackend ?

Yes, here you are using our general-purpose POSIX backed. And It is guaranteed (now and in the future) to be everything-safe

[owny990312]

Hello, @owny990312 ! This is a tricky question.这是一个棘手的问题。 The thread safety of shm provider and allocation layout API's depend on provider's backend. If the backend is thread-safe, the whole provider with all it's API will also be thread-safe.shm 提供者和分配布局 API 的线程安全性取决于提供者的后端。Hello, @owny990312 ! 这是一个棘手的问题。shm 提供者和分配布局 API 的线程安全性取决于提供者的后端。如果后端是线程安全的，那么整个提供者及其所有 API 也将是线程安全的。如果后端是线程安全的，那么整个提供者及其所有 API 也将是线程安全的。 Our general-purpose PosixShmProviderBackend is thread-safe.我们的通用 PosixShmProviderBackend 是线程安全的。 If you are using your own C-callback-based backend implementation, the thread-safety will depend on it如果你使用的是自己的基于 C 回调的后端实现，线程安全性将取决于它
SHM Api is marked unstable and thus we are still polishing it. Your question raises a good point to improve, thank youSHM Api 标记为不稳定，因此我们仍在对其进行完善。您的问题提出了一个很好的改进点，谢谢。SHM Api 标记为不稳定，因此我们仍在对其进行完善。您的问题提出了一个很好的改进点，谢谢。

Thanls for your reply.  谢谢您的回复。
How to set its provider's backend, if we use如何设置其提供者的后端，如果我们使用

    z_posix_shm_provider_new(&shm_provider_, z_loan(shm_layout_));

it means we set general-purpose PosixShmProviderBackend ?它意味着我们设置了通用的 PosixShmProviderBackend？

Yes, here you are using our general-purpose POSIX backed. And It is guaranteed (now and in the future) to be everything-safe是的，您正在使用我们的一般用途的 POSIX 兼容版本。并且现在和将来都保证是安全的。

Thanks for your reply

[yellowhatter]

@owny990312 However, if your system design might produce high contention around the provider (a lot of overlapping concurrent calls of it's API), maybe it is worth thinking about having a provider's instance per thread, otherwise the contention might degrade the performance. We have plans to optimize our default provider, and these plans also include good improvements for described scenario, but currently it is not perfect