Protecting against concurrent requests

Josh Milburn
 

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 iotivity-dev@iotivity.groups.io to automatically receive all group messages.