Bluetooth Mesh stack question

[venngar]

Hello!

I've been developing a complex project involving Bluetooth Mesh API, and I have a question regarding that. In your documentation, you say that Bluetooth API is thread safe unless it's written otherwise:

https://docs.zephyrproject.org/latest/connectivity/bluetooth/bluetooth-dev.html#thread-safety

Calling into the Bluetooth API is intended to be thread safe, unless otherwise noted in the documentation of the API function. The effort to ensure that this is the case for all API calls is an ongoing one, but the overall goal is formally stated in this paragraph. Bug reports and Pull Requests that move the subsystem in the direction of such goal are welcome.

But my understanding is that it touches only classic Bluetooth API, and not the Mesh. Can you please clarify if Bluetooth Mesh is thread-safe or not?

[carlescufi]

@PavelVPV FYI

[PavelVPV]

You should only call Bluetooth Mesh API from a cooperative thread. Do not use the system workqueue to call a synchronous Bluetooth Mesh API as it will block the execution of the mesh stack until the API timeout expires. An example of such API will Config Client or Health Client APIs that use bt_mesh_msg_ack_ctx_match function (https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/bluetooth/mesh/msg.h#L257-L258) to receive a response in the same execution context. For example, calling bt_mesh_cfg_cli_app_key_add with supplied status argument from the system workqueue will block sending the Config AppKey Add message until this call times out. In such case, the API will return ETIMEDOUT error.

[venngar]

Ah, now it's more clear, thank you. In that case, theoretically will the solution of creating a separate workqueue specifically for mesh publishing with the same priority as system workqueue suffice?

Because, as I understand, making the workqueue with higher priority than system workqueue will block the latter and everything that's scheduled in it.

[PavelVPV]

It can have the same priority as the system workqueue, but remember to not run any heavy blocking tasks to block execution of other cooperative threads, which is a usual requirement for the cooperative threads and which also applies to workqueue items (https://docs.zephyrproject.org/latest/kernel/services/scheduling/index.html#cooperative-time-slicing):

Consequently, if a cooperative thread performs lengthy computations, it may cause an unacceptable delay in the scheduling of other threads, including those of higher priority and equal priority. To overcome such problems, a cooperative thread can voluntarily relinquish the CPU from time to time to permit other threads to execute.

[venngar]

Excellent, thank you for the information! This will get useful

[PavelVPV]

@venngar, could you please mark the question as answered?

[venngar]

Done, and thanks once again!