diff options
| author | Sven Gothel <[email protected]> | 2020-09-18 05:51:22 +0200 |
|---|---|---|
| committer | Sven Gothel <[email protected]> | 2020-09-18 05:51:22 +0200 |
| commit | 97951027dc06ef419383925e86bd6f2143dfd51d (patch) | |
| tree | a7ef35d8ba58702a0178fe1f040185858d353f68 /examples/java/AsyncTinyB.java | |
| parent | 5878830cd6dcb18c2cab53bb47e82e94d6c75d79 (diff) | |
DBTDevice: Resolve disconnect/remove resource race condition @ rapid connect w/ one thread per devicev2.1.22
Testing w/ 2 devices in fastest rapid reconnect (using automatic disconnect) on Raspberry-Pi:
(1) Native run-dbt_scanner10.sh -silent_gatt -mac C0:26:DA:01:DA:B1 -mac C0:26:DF:01:E5:CA -disconnect -count 12
(2) Java run-java-scanner10.sh -silent_gatt -mac C0:26:DA:01:DA:B1 -mac C0:26:DF:01:E5:CA -disconnect -count 12
The Java (2) test case disclosed a race condition as follows:
"An application using one thread per device and rapid connect, should either use disconnect() or remove(),
but never issue remove() after disconnect(). Doing so would eventually delete the device being already
in use by another thread due to discovery post disconnect!"
The example code was issuing (1) disconnect and waiting for being diconnected and only then
(2) removing the device. In between the device got discovered already and a new processing thread has started
while the closing previous processing thread is removing the device and hence the underlying DBTDevice.
A user shall either use disconnect() or remove(), period.
Diffstat (limited to 'examples/java/AsyncTinyB.java')
0 files changed, 0 insertions, 0 deletions