If you have a situation that two threads may call oc_init_post then you must prevent both threads calling oc_init_post at the same time. You must add a mutex or some other similar guard before calling oc_init_post and then you can release
it after calling oc_do_post. The same is true for oc_init_put and oc_do_put.
From: email@example.com <firstname.lastname@example.org>
On Behalf Of josh@...
Sent: Wednesday, June 3, 2020 11:00 PM
Subject: [dev] Protecting against concurrent requests
I'm particularly interested in how the following scenario is prevented:
1. Code from one thread ("A") in the application calls `prepare_coap_request` (which in turn, calls `oc_rep_new`, resetting the current CBOR encoder state). For example, this might happen by someone calling `oc_init_post`.
2. Thread "A" sees a 'success' from `oc_init_post`, and calls `oc_rep_begin_root_object` and begins building a request body
3. Thread "A" is interrupted by higher priority thread "B" which calls `oc_init_post`.
4. Thread "B" completes and sends request
5. Control is returned to thread "A", which continues trying to build a request body, but the data is now meaningless (since the state of `g_encoder` and `root_map` in `oc_rep.h` have been modified
Looking over the example apps, most seem to provide protection against this by ensuring that requests are not created in interrupts, and/or requests are sent via a menu driven interface. Are there further safeguards against this
concurrency issue, is it actually a nonissue, or am I misunderstanding something here?