Hi all, I looked into reasons that are causing IoTivity to wake up the CPU continuously and found 2 issues:
1. IOT-1828<https://jira.iotivity.org/browse/IOT-1828> ? applications calling OCProcess continuously in a loop. 2. IOT-1930<https://jira.iotivity.org/browse/IOT-1930> ? extlibs/timer is spinning endlessly (?loop()? thread start routine). For issue #1, I?m working on a fix to eliminate the need for applications to spin the OCProcess thread as discussed by Soemin below. The idea is for IoTivity stack to spin an extra thread to do the tasks that OCProcess is doing today, serially. And since the thread is owned by the stack, it will also manage when to run and when to idle the worker thread. Note that this work will not change the behavior of apps on Arduino since no worker threads can be spun on Arduino (this is guarded by SINGLE_THREAD define). So this work will only be in non-SINGLE_THREAD build. The existing OCProcess will be left alone for backward compatibility, but a deprecated warning (and @deprecated) will be shown if it is called from platforms other than Arduino. I?m also planning to update all the sample apps to take advantage of the new behavior. For apps that do not opt-in to the new model (i.e., those that still call OCProcess in a dedicated loop), they should only get a warning in the log. Functionalities will not be impacted. Please let me know if there are any concerns and feel free to send feedbacks my way. Thanks, Way From: Soemin Tjong Sent: Thursday, March 9, 2017 10:05 PM To: ce.abhishek at samsung.com Cc: iotivity-dev at lists.iotivity.org; Way Vadhanasin <Wayakorn.Vadhanasin at microsoft.com> Subject: RE: [dev] Make OCProcess( ) needed only on single threaded platform Hi Abhishek, you are saying that there could be issues in running the 4 functions in multithreading scenario. That?s a good point, but perhaps the issues can be minimized by synchronizing the running of the 4 threads (at least for now), until issues are resolved. That way, we would still get the desire effects of not waking up unnecessarily. It?s not clear what you meant by csdk users not handling multi-thread scenario, can you describe more? I assume the users of the csdk apis are the (sample) apps, security, and C++ (OCPlatform, OCResource). And your point is that these apps could now get simultaneous calls from the 4 functions. If so then yes, it will need to be resolved as well after the stack side is fix. Or another possibility is to let the apps opt in. Thanks for the info Abhishek. From: Abhishek Sharma [mailto:[email protected]] Sent: Thursday, March 9, 2017 9:31 PM To: Soemin Tjong <stjong at exchange.microsoft.com<mailto:stjong at exchange.microsoft.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; Way Vadhanasin <Wayakorn.Vadhanasin at microsoft.com<mailto:Wayakorn.Vadhanasin at microsoft.com>> Subject: RE: [dev] Make OCProcess( ) needed only on single threaded platform Agree it would be great if app developers need not worry about popping that extra thread to keep calling OCProcess(). But I think removing this function now would be tricky and not limited to just removing single api. All users of csdk api's will require handling of multi-thread scenario, which they most probably might not be doing now. Also csdk (oc* files) will have to be reviewed to support multi-threading, for ex: global variables will have to be removed or put under lock. CA layer (ca* files) was designed to be multi-threaded from begining so you will face no issues there. Regards Abhishek Sharma --------- Original Message --------- Sender : Soemin Tjong <stjong at exchange.microsoft.com<mailto:stjong at exchange.microsoft.com>> Date : 2017-03-10 08:09 (GMT+5:30) Title : [dev] Make OCProcess( ) needed only on single threaded platform Hi all, we are investigating https://jira.iotivity.org/browse/IOT-1828<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-1828&data=02%7C01%7Cstjong%40exchange.microsoft.com%7C4b7f0cb9bddb4964bd8d08d46776a638%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636247206678818084&sdata=y%2BeydPdFTFUoy9BsBe5I%2BrIv%2F1nNMu4NkOkAMrJUEg8%3D&reserved=0> and can use some input. Currently code that uses ocstack needs to periodically call OCProcess( ) (most call it every 10 ms). The OCProcess( ) performs 4 functions: (1) process received packets, (2) handle presence, (3) handle gateway routing, and (4) handle TCP keepalive. Waking up often is not great for applications running on battery operated devices. We think calling OCProcess() should only be needed on single threaded platforms, like Arduino (i.e. when SINGLE_THREAD is defined). Looking at camessagehandler.c, it seems like the IoTivity code was at some point able to handle its own send & receive. Then SINGLE_HANDLE flag was set permanently and function (1) is now handled by periodic OCProcess( ) instead. Does anyone know the history of SINGLE_HANDLE? We want to propose making OCProcess( ) needed only on single threaded platform. To do that we?ll re-enable the receive thread, remove all references to SINGLE_HANDLE, and subsequently add new thread(s) to perform function 2 to 4. Can anyone think why this won?t work? Thanks! _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev [cid:image001.png at 01D2A365.9777A230] [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=ce.abhishek&do=bWFpbElEPTIwMTcwMzEwMDUzMTAxZXBjbXM1cDg4MTIwNGExMjExMTlhYWJkMTQzMzQ2Yzk4NWMzODk0NCZyZWNpcGllbnRBZGRyZXNzPXN0am9uZ0BleGNoYW5nZS5taWNyb3NvZnQuY29t] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170323/c0d78bde/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33527 bytes Desc: image001.png URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170323/c0d78bde/attachment.png>
