https://bugs.kde.org/show_bug.cgi?id=368438
--- Comment #8 from Matt Whitlock <k...@mattwhitlock.name> --- (In reply to Albert Vaca from comment #7) > Is there a way I can reproduce it? I'm not sure. KDE Connect is broken for me more often than it works, and I still don't know the exact conditions that cause it to enter the failure mode. I know that rebooting my phone makes it work again for a while. In fact, I did that just now, and now KDE Connect is connected and I can ring my phone from my computer's KDE Connect tray panel. > Does simply adding volatile fixes it for you? I don't have an Android development environment, and I don't know the first thing about developing apps for Android. I'm a Java developer, not an Android developer. > If this was the case, there are probably many more volatile > missing, so I would like to have a way to check the effect of > adding/removing them. Data races are probabilistic and as such are notoriously difficult to reproduce reliably, as they depend on factors outside of the program being tested, such as the global state of the operating system and the specifics of the OS kernel's thread scheduler. Rather than measuring the effects of declaring variables volatile, which sounds a lot like "programming by accident" (https://en.wikipedia.org/wiki/Programming_by_permutation), you should reason about which variables need to be declared volatile. Generally, if you access a variable from more than one thread without any kind of synchronization between the threads, then you must declare the variable volatile. And for what it's worth, Thread.sleep(…) is not a synchronization primitive. In general, there is no upper bound on the amount of time that a thread may be paused between instructions, so you cannot pick any delay time for Thread.sleep(…) that is guaranteed to be long enough. Use proper thread synchronization techniques instead. -- You are receiving this mail because: You are watching all bug changes.
