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.
George Nash From: [email protected] <[email protected]> On Behalf Of [email protected] Sent: Wednesday, June 3, 2020 11:00 PM To: [email protected] 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? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#10388): https://iotivity.groups.io/g/iotivity-dev/message/10388 Mute This Topic: https://groups.io/mt/74666318/21656 Group Owner: [email protected] Unsubscribe: https://iotivity.groups.io/g/iotivity-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
