# Multithreading with software timers **URL:** \ **Category:** Firmware\ **Created:** [February 9, 2016, 10:57pm UTC](https://community.particle.io/t/multithreading-with-software-timers/19905 "2016-02-09T22:57:20Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![G65434\_2](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/g65434_2/32/6236_2.png) [@G65434\_2](https://community.particle.io/u/G65434_2)\ **Post date:** [February 9, 2016, 10:57pm UTC](https://community.particle.io/t/multithreading-with-software-timers/19905/1 "2016-02-09T22:57:20Z")
Hi all I’m trying to get a better understanding of how multi-threading works, especially while connecting to the cloud. It’s my understanding that ISRs would still be serviced while connecting to WiFi or the cloud… What about software timers? I, like a few others I’ve read posts from have a product that must remain responsive, even if a users internet goes out. At the moment my whole program hangs for about 8 seconds+ while connecting to WiFi and then the cloud. Not so much of a problem if it only happens at startup but if a user has an inconsistent connection, then regular cloud connection attempts can really make the program unusable. I’m aware there are a few different system modes, I’m currently experimenting with SEMI\_AUTOMATIC, although I don’t see how this will help me that much, as ‘connecting’ to WiFi or the cloud still appears to be completely blocking. I’m running 0.4.9 and my understanding was that connecting to WiFi and the cloud was not a blocking call. Any ideas? ---
**Author:** ![Moors7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/moors7/32/588_2.png) [@Moors7](https://community.particle.io/u/Moors7)\ **Post date:** [February 9, 2016, 11:09pm UTC](https://community.particle.io/t/multithreading-with-software-timers/19905/2 "2016-02-09T23:09:13Z")
Have you tried this yet? [https://docs.particle.io/reference/firmware/photon/#system-thread](https://docs.particle.io/reference/firmware/photon/#system-thread) ---
**Author:** ![G65434\_2](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/g65434_2/32/6236_2.png) [@G65434\_2](https://community.particle.io/u/G65434_2)\ **Post date:** [February 9, 2016, 11:30pm UTC](https://community.particle.io/t/multithreading-with-software-timers/19905/3 "2016-02-09T23:30:12Z")
Thanks for your reply @Moors7 I did have SYSTEM\_THREAD(ENABLED) in there. Just realised it was not in fact my software timers that were blocking but calls to Particle.publish within the software timer callbacks. I’ve put a Particle.connected() conditional around these now and we’re good to go. Noob mistake sorry! ---
**Author:** ![Moors7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/moors7/32/588_2.png) [@Moors7](https://community.particle.io/u/Moors7)\ **Post date:** [February 9, 2016, 11:43pm UTC](https://community.particle.io/t/multithreading-with-software-timers/19905/4 "2016-02-09T23:43:37Z")
I think you should be treating those timer callbacks like ISR, that is, keep them as light as possible. Don’t try to do fancy cloud stuff in them, but rather set a flag for the main loop to check on. That should prevent any timer issues that might come to existence when calling things like that on ‘dedicated stuff’. (Does that make sense?) ---
**Author:** ![G65434\_2](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/g65434_2/32/6236_2.png) [@G65434\_2](https://community.particle.io/u/G65434_2)\ **Post date:** [February 10, 2016, 1:30am UTC](https://community.particle.io/t/multithreading-with-software-timers/19905/5 "2016-02-10T01:30:04Z")
Good point thanks, I’ve moved some more of my code out of the software timers 😄 ---
**Author:** ![MORA](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mora/32/8575_2.png) [@MORA](https://community.particle.io/u/MORA)\ **Post date:** [February 10, 2016, 9:10pm UTC](https://community.particle.io/t/multithreading-with-software-timers/19905/6 "2016-02-10T21:10:57Z")
I use this “avr” lib for simple timers : [https://github.com/Zuph/AVRQueue](https://github.com/Zuph/AVRQueue) That way you only have to call one function every so often and it takes care of calling the tasks on their schdule, its not multithreaded, but takes the boiler plate code away from having to maintain a number of variables with millis() etc. If you use system\_threading and then call that lib from the loop function, maybe you get acceptable performance during wifi connecting.