What are the best practices when processing BLE GAP scan events to avoid multi-threading issues?
I programmed the nrf52832 to successfully read BLE GAP events coming from multiple beacon devices from my environment.
I current parse and copy the BLE event data into a "data queue" for further processing by my application.
But it occurs to me there can be multi-threading issues here, since I believe the application has at least two threads operating:
BLE event handling thread writes to the data queue.
Main loop thread reads the data queue.
The data queue is a shared resource.
The data queue is implemented as an ordered list of data nodes.
QUESTIONS:
1. How can I assure multi-threading issues are avoided with the Softdevice library and application?
2. If BLE data is stored in the data queue SHARED by both the event handler thread and the main loop thread, will there be a thread contention issue?
3. Is it best to create a multithread safe, semiphore lock around the data queue?
But a semiphore lock will BLOCK the handler thread to continue forward, when the main loop thread is reading from the queue.
4. Would Blocking the BLE handler thread create problems with Nordic BLE Softdevice processing?
5. Would it be best to copy BLE handler events into a data staging area and then have the application thread copy the data staging area into the data queue?
In this case, the application thread would need to know when to copy from staging area to data queue such as wait for Softdevice events to be quiescent.
My Setup:
nrf52832
SoftDevice S132 v15.2.0 firmware.
I setup a scan event handler:
NRF_SDH_BLE_OBSERVER(mtag_ble_observer, APP_BLE_OBSERVER_PRIO, bluetooth_ble_ble_evt_handler, NULL);
Then capture the events in a handler:
void bluetooth_ble_ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
switch (p_ble_evt->header.evt_id)
{
case BLE_GAP_EVT_ADV_REPORT:
// PROCESS DATA HERE...
break;
}
}
I am interested in hearing any and all ideas from developers -- and things to avoid.
I hoping for a reliable and simple solution.
Regards,
Ken Huebner
Software Engineer
