D22182: Remove anchorClicked lock which causes deadlock

[Michael Swan]

mswan added a comment.


  In D22182#490522 <https://phabricator.kde.org/D22182#490522>, @aaronpuchert wrote:
  
  > In D22182#489873 <https://phabricator.kde.org/D22182#489873>, @mswan wrote:
  >
  > > This should definitely be tried and I would be interested in the task. There is definitely quite alot of stuff that needs to be annotated to make this work so it might need several hands working on it.
  >
  >
  > I'd be delighted and would happily work with you on this. I worked on the Thread Safety Analysis feature for a while.
  >
  > > The one problem with adopting that system in KDevelop is that we copy `DUChain::lock()` into each instance of `DUChain{Read,Write}Locker` which means that our annotations wouldn't see the `DUChainReadLocker` in one instance as the same lock in another instance.
  >
  > I don't think the lock is copied, it's just a pointer to it. That's not an issue, `std::lock_guard` does that as well. Note that `DUChainLock` would be annotated with `__attribute__((capability("mutex")))`, but `DUChainReadLocker` with `__attribute__((scoped_lockable))`. The analysis tracks which scoped capability owns which capability.
  >
  > > Since I have never seen `DUChain{Read,Write}Locker` used with anything other than `DUChain::lock()`
  >
  > Wondered about this as well—the constructor allows specifying any lock, but this is used only with `DUChain::lock()`.
  >
  > > this shouldn't be cause for false positive deadlock detection.
  >
  > Deadlock detection needs to turned on separately anyway. (With `-Wthread-safety-negative`, because it requires "negative capabilities", i.e. someone not having a lock as opposed to having it.)
  >
  > I wouldn't worry too much about that for now.
  
  
  Interesting. I have experimented with this a bit and I cannot find a way to articulate to the thread safety system that my lock and unlock functions are idempotent. If I call `lock.unlock()` and later return without locking it again, I get a warning (or rather an error because I set `-Werror=thread-safety`) that complains that I am releasing a lock that isn't held. So would `-Wno-error=thread-safety-negative` allow us to get around that or is there possibly some other solution?

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D22182

To: mswan, #kdevelop
Cc: aaronpuchert, kdevelop-devel, hmitonneau, christiant, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20190704/124cf8ea/attachment.html>