Re: Protecting against concurrent requests

George Nash

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: <> 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?

Join to automatically receive all group messages.