misc/lock-monitor/lock-monitor.c
static int lockcmp(const void *a, const void *b) {
    struct list *l;

    /* Optimisation to avoid locking. */
    if (a == b) return 0;

    real_mutex_lock(&ordering_lock);
    assert(known(a));
    assert(!b || known(b));
    l = ordering;
    real_mutex_unlock(&ordering_lock);

    for (; l; l = l->next) {
        if      (l->value == a) return 1;
        else if (l->value == b) return -1;
    }

    /* If we've reached this point than neither lock was found in the ordering
     * information, which means something has gone unexpectedly wrong (the
     * pre-loop assertions should have caught this).
     */
    lock_monitor_exception("Lock Monitor: lockcmp failure while comparing "
        "locks %p and %p.\n", a, b);
    /* Unreachable. */
    return 0;
}
/* Compare two locks via the partial ordering. Both locks must be in the
 * partial ordering already. The exception is when b is NULL, in which case it
 * will be absent. It is not assumed that the callee holds any locks. Returns
 * <0 when a is lesser, >0 when b is lesser, 0 when the locks are the same. As
 * with thread_list, we exploit the fact that we know nodes are not removed
 * from ordering and are only ever added to the front of the list. Therefore it
 * is OK to only lock ordering_lock on direct reading from ordering.
 */
Compare two locks via the partial ordering. Both locks must be in the
partial ordering already. The exception is when b is NULL, in which case it
will be absent. It is not assumed that the callee holds any locks. Returns
<0 when a is lesser, >0 when b is lesser, 0 when the locks are the same. As
with thread_list, we exploit the fact that we know nodes are not removed
from ordering and are only ever added to the front of the list. Therefore it
is OK to only lock ordering_lock on direct reading from ordering.
Compare two locks via the partial ordering . Both locks must be in the partial ordering already . The exception is when b is NULL in which case it will be absent . It is not assumed that the callee holds any locks . Returns <0 when a is lesser > 0 when b is lesser 0 when the locks are the same . As with thread_list we exploit the fact that we know nodes are not removed from ordering and are only ever added to the front of the list . Therefore it is OK to only lock ordering_lock on direct reading from ordering .
static int lockcmp(const void *a, const void *b) {
    struct list *l;
    if (a == b) return 0;
    real_mutex_lock(&ordering_lock);
    assert(known(a));
    assert(!b || known(b));
    l = ordering;
    real_mutex_unlock(&ordering_lock);
    for (; l; l = l->next) {
        if      (l->value == a) return 1;
        else if (l->value == b) return -1;
    }
    lock_monitor_exception("Lock Monitor: lockcmp failure while comparing "
        "locks %p and %p.\n", a, b);
    return 0;
}
static int lockcmp ( const void * a , const void * b ) { struct list * l ; if ( a == b ) return 0 ; real_mutex_lock ( & ordering_lock ) ; assert ( known ( a ) ) ; assert ( ! b || known ( b ) ) ; l = ordering ; real_mutex_unlock ( & ordering_lock ) ; for ( ; l ; l = l -> next ) { if ( l -> value == a ) return 1 ; else if ( l -> value == b ) return -1 ; } lock_monitor_exception ( " " " \n " , a , b ) ; return 0 ; }
Compare two locks via the partial ordering.
Compare two locks via the partial ordering .
/* Optimisation to avoid locking. */ /* If we've reached this point than neither lock was found in the ordering
     * information, which means something has gone unexpectedly wrong (the
     * pre-loop assertions should have caught this).
     */ /* Unreachable. */