title: why the lock field of Linux kernel's rwlock_t is unsigned int
body: <p>In Linux 2.6.11.12, the <code>rwlock_t</code> is defined like this:</p>
  
  <pre><code>typedef struct {
      volatile unsigned int lock;
  #ifdef CONFIG_DEBUG_SPINLOCK
      unsigned magic;
  #endif
  #ifdef CONFIG_PREEMPT
      unsigned int break_lock;
  #endif
  } rwlock_t;
  </code></pre>
  
  <p>In the definition of <code>rwlock_t</code>, the <code>lock</code> field is <code>unsigned int</code>. When we want to get a read lock, <code>read_lock()</code> will eventually call the <code>_raw_read_trylock()</code></p>
  
  <pre><code>static inline int _raw_read_trylock(rwlock_t *lock)
  {
      atomic_t *count = (atomic_t *)lock;
      atomic_dec(count);
      if (atomic_read(count) &gt;= 0)
          return 1;
      atomic_inc(count);
      return 0;
  }
  </code></pre>
  
  <p>In this function, we call <code>atomic_dec()</code> to decrease the <code>lock</code> and check whether it is greater than or equal to zero. But <strong>since the <code>lock</code> is an <code>unsigned int</code>, <code>lock</code> will always greater than 0!</strong> That is, this function will always return 1.</p>
  
  <p>I guessed that the <code>atomic_read()</code> convert the result to a <code>int</code>, but in i386 arch, it is defined as</p>
  
  <pre><code>#define atomic_read(v)      ((v)-&gt;counter)
  </code></pre>
  
  <p>and I have no idea how <code>unsigned int lock</code> works.</p>