Skip to content
Snippets Groups Projects
  1. Apr 29, 2011
  2. Mar 16, 2011
    • Michael Hanselmann's avatar
      locking: Fix race condition in lock monitor · e4e35357
      Michael Hanselmann authored
      
      In some rare cases it can happen that a lock is re-created very soon
      after deletion, while the old instance hasn't been destructed yet. In
      such a case the code would detect a duplicate name and raise an
      exception.
      
      We have seen at least one case where this happened during the creation
      of many instances. It is not exactly clear how it came to be, but it
      appears to have occurred while different jobs fought for locks with
      short timeouts (in the case of instance creation locks are added at this
      stage and removed shortly after if not all locks can be acquired).
      
      The issue is fixed by removing the check for duplicate names. To still
      guarantee a stable sort order for the lock information as shown by
      “gnt-debug locks”, a registration number is recorded for each lock in
      the monitor.
      
      A unittest is included to check for the situation.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      e4e35357
  3. Jan 06, 2011
  4. Dec 06, 2010
  5. Dec 01, 2010
  6. Nov 16, 2010
  7. Oct 28, 2010
  8. Sep 24, 2010
  9. Sep 10, 2010
  10. Sep 07, 2010
  11. Aug 27, 2010
  12. Aug 24, 2010
    • Michael Hanselmann's avatar
      Add simple lock monitor · 19b9ba9a
      Michael Hanselmann authored
      
      This patch adds an initial implementation of a lock monitor, accessible
      for the user through “gnt-debug locks”. It currently shows all resource
      locks: BGL, nodes and instances. Config and job queue locks could be
      shown too, but wouldn't be of much help.  The current owner(s) and mode
      are also shown.
      
      Showing pending acquires will require further changes on the SharedLock
      internals and is not yet implemented.
      
      Example output:
      $ gnt-debug locks -o name,mode,owner
      Name            Mode      Owner
      BGL/BGL         shared    JobQueue19/Job147
      instances/inst1 exclusive JobQueue19/Job147
      instances/inst2 -         -
      instances/inst3 -         -
      instances/inst4 -         -
      nodes/node1     exclusive JobQueue19/Job147
      nodes/node2     exclusive JobQueue19/Job147
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      19b9ba9a
  13. Aug 23, 2010
  14. Jul 16, 2010
    • Iustin Pop's avatar
      Implement lock names for debugging purposes · 7f93570a
      Iustin Pop authored
      
      This patch adds lock names to SharedLocks and LockSets, that can be used
      later for displaying the actual locks being held/used in places where we
      only have the lock, and not the entire context of the locking operation.
      
      Since I realized that the production code doesn't call LockSet with the
      proper members= syntax, but directly as positional parameters, I've
      converted this (and the arguments to GlobalLockManager) into positional
      arguments.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      7f93570a
  15. Jun 28, 2010
  16. Jun 11, 2010
  17. Jun 10, 2010
  18. Apr 21, 2010
  19. Feb 10, 2010
  20. Jan 27, 2010
  21. Jan 13, 2010
  22. Jan 04, 2010
  23. Dec 28, 2009
  24. Nov 25, 2009
  25. Oct 15, 2009
  26. Oct 13, 2009
  27. Oct 12, 2009
  28. Oct 02, 2009
  29. Oct 01, 2009
    • Guido Trotter's avatar
      SingleActionPipeCondition =~ s/Action/Notify/ · 34cb5617
      Guido Trotter authored
      
      With this patch we simplify usage on the SingleActionCondition (which
      wasn't a condition at all) by making it a real condition. This way we
      can just wait() on it, or notifyAll() as we would on a normal one. The
      only catch is that notifyAll can be called only once, and wait can only
      be called before notifyAll has, but luckily our PipeCondition, now quite
      simplified, takes care of this, by providing a new SingleActionCondition
      each time the previous one has been notified.
      
      No Start/StopUsing function are needed anymore, and thus the condition
      is a lot more robust, and there's no way file descriptors can be left
      open, as they are closed in a finally block, in the same function where
      they were opened, by the last thread exiting the class.
      
      Signed-off-by: default avatarGuido Trotter <ultrotter@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      34cb5617
Loading