by a strange coincidence, so have I :) so I might be wrong, take whatever
I say with a pinch of salt.
> void interrupt_handler(...)
> {
> unsigned long flags;
>
> spin_lock_irqsave(&spinlock, flags);
> /* Stuff on structure */
> spin_unlock_irqrestore(&spinlock, flags);
> }
since you are already inside the interrupt handler, (and presumably there
are no other interrupt handlers accessing the same structure), all you
have to protect against are your threads. no need to save irq. so
spin_lock and spin_unlock should be adequate.
> #define lock_struct(flags) \
> spin_lock_irqsave(&spinlock, flags); \
> down(&lock);
this looks like overkill since the spinlock also provides mutual exclusion
for the thread accesses. semaphores are BLOCKING primitives which should
be used only when you might be holding the resource for a long time. since
you are accessing the structure from an interrupt handler, I assume that
your critical regions are small. otherwise you might keep your interrupt
handler spinning for a long time.
spin_lock_irqsave(&spinlock, flags) should be sufficient to ensure mutual
exclusion in the threads. you don't need the semaphore.
besides, it makes me nervous to see a down() after acquiring a spinlock.
down could block, and blocking while holding a spinlock is not allowed
because it can cause deadlocks. of course your code doesn't look likely
to deadlock, but it's better to avoid such constructs altogether.
I have a question on semaphores too:
why do we use the waking field and wake up everyone in the wait queue,
instead of just taking one guy off and waking him up ?
my guess is that the queue is not ordered in any way and this lets the
scheduler pick the highest-priority process to win the race.
HTH.
ganesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/