Dear Vijay... > "..top half to service a new interrupt while the bottom half is still > working" > > What would the situation be if the bottom half is waiting on a spin > lock and at the same time another interrupt of the same handler has > arrived. Hm....that would greatly decrease system scalability and perfomance... IMHO, bottom halves should be a lockless operations as much as it can. To provide atomicity, you might temporarily disables interrupt on another irq which might access the same. No need to be afraid of your interrupt handler being preempted by same handler sitting on same irq, it is masked out by default do_irq() IIRC. The exception is the interrupt handler installed with SA_INTERRUPT, which is running with all interrupts enabled. > Example: > I have a global varible which is accessed only by getting the spin > lock.This variable is accessed only in bottom half.Based on the info > obtained from the top half, the global variable is set in the bottom > half.Suppose an interrupt has occured, the top half is executed and > the required info is sent to the bottom half for a later execution. > In the bottom half, i wait for the availability of a spin lock to > access the variable. At the same time, if another interrupt occurs > and changes the info given to the bottom half, does this create a > loss of the interrupt handling in the bottom half? Well, that would be a terrible example IMHO. Bottom halves are created to defer work...so if they also wait for a lock which might be held by top half on certain occasions....you can imagine that it would drop the kernel perfomance. >Is there any other > way by which this kind of race condition can be avoided? I suggest: 1. if you think the work is fast enough (yes, I truly mean real fast, not just "i think it is fast") and doesn't need any blocking operation (such as page allocation using GFP_KERNEL/USER) and doesn't need to access certain process address space, just put all the works on the top half. 2. Maybe this is better. I guess you want to store a series of values from top half and access them all without even missing a single value later (on more relaxed context), right? If so, any approach you will take to solve it, the variable (or the list which hold the values) will be the bottleneck, no matter what. In this case, try to reduce the time you need to access/update the variable, so lock is held in such a short time. To increase value consistency, try to declare you variable as "volatile". Use list_for_each_safe() for traversing the list in safe manner. >Is it a good > practise to wait on a spin lock in the bottom half?? Actually, IMHO no, but in the real world, as you see on Linux kernel codes, it is still used on certain places. The recipe is: do it lockless. If you can't, just do it as fast as you can. on SMP system, consider per CPU variable to increase scalability, of course...if your data is also per CPU specific. Use reader-writer lock to increase concurrency. Hope it helps.... regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
