JDevlieghere wrote: > Someone once told me: "Whatever problem you're trying to solve, if you're > using atomics, now you've got two problems." > > I can't say I've always followed that advice, but I do think that atomics are > rarely the right solution to a problem. And I think this is a good example of > that. > > What you want is not to suppress _a_ event (whatever it might be). You want > to suppress a very specific event (that is supposed to be generated by the > action you're about to perform). That means that something needs to ensure > that the other thread reads this flag after you've generated the event. If > that's true, then you already have a happens-before relationship and the > atomic is not necessary. If it isn't (there is no happens-before), then the > atomic will not help.
You're right. I have an implementation that used a mutex but it made the same mistake I have here with the atomic. Luckily that's easily solvable by putting the code that generates the stop and consumes the stop in the critical section. > That said, why is ConnectRemote generating a stopped event in synchronous > mode? Maybe that's the bug we should fix? That's a long standing bug that comes up about once or twice a year. I spend some time looking into that at some point, but it's so long ago that I don't remember what the blocker was. That said, solving that isn't sufficient for the problem at hand, since we need to solve the asynchronous case as well. https://github.com/llvm/llvm-project/pull/137920 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
