[Click] Spinlock, ownership bug?

[Paine, Thomas Asa]

        I have a case where a Timer's unshcedule() and schedule_at() methods can be called by two different threads.  The Element containing the Timer is protected by ReadWriteLocks, so theoretically only one thread can be scheduling the timer at a time.  However, I experience deadlocks at the point were these operations should be otherwise atomic.  One of the Threads is always the main click thread.  The other thread is coming in via a write handler.
        I'm guessing the deadlock is possibly a result of master->_timer_lock.acquire() using Spinlock and not ReadWriteLock?  Likewise, if there is going to be a depth counter in Spinlock, shouldn't _owner be a "thread" and not a "my_cpu"?  Otherwise, doesn't there exist the potential for two threads, which may happen to run on the same cpu, to both be the "owner" of that lock, thus rendering the operation depending on the lock, non-atomic.  The result... a call to acquire() would result in depth incrementing, the acquire() succeeding, and two threads operating in the same critical section of code.  Does that potential currently exist?

Thanks,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Thomas Paine (paineta at uwec.edu)
   University of Wisconsin - Eau Claire
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~