[Click] Spinlock, ownership bug?

[Eddie Kohler]

Click basically assumes that no Click thread will be preempted while holding a 
Spinlock.  If that is the case, then you can never have two threads on the 
same CPU attempting to acquire the same spinlock; one will win, and the other 
will not run until the first has relinquished the lock.  Again I wonder if 
your kernel is running with CONFIG_PREEMPT?

Eddie


Paine, Thomas Asa wrote:
>         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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click