You would only get a race condition if the suspend code is contending
the same lock as the thread. Unlikely if there is no locking.
The kernel does not stop kthreads when suspending.
Each kthread that runs a main loop should call try_to_freeze() in its
main loop. This will let it detect the suspend and put it in the
refrigerator while it is in suspend.
If you need a kthread, then generally the suspend handler should wake it
up from whatever wait state it is in, and the thread would immediately
call try_to_freeze().
If you are only using the kthread as a defered interrupt handler (i.e.
it only does work as a response to a raised interrupt), then you should
just use a deferred interrupt handler. See request_threaded_irq for
details (kernel/irq/manage.c). The request_threaded_irq call is there
for doing exactly this sort of thing (and is what the plain request_irq
will call underneath). Using this, there is no need to have your own
thread, and it avoids having to do your own signalling between the isr
and thread.
Regards
Bob
On 30/08/11 00:58, scorproy wrote:
Hello,
If I have a driver with the following setup, on an SMP system:
1. When IRQ is high, ISR is fired, which schedules a work function,
and also sets a completion flag
2. A kthread is being in the background, with an infinite whole loop.
which waits for this completion
3. Upon completion, process the work, and again goes back to wait.
My queries are as follows:
1. If I am doing a suspend, on an smp system, can there be a race
condition between the driver suspend code
and the the kthread code?
2. Does the kernel take care that when the kernel starts to to call
suspend, all the kthreads are stopped?
Thanks,
Arindam
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-kernel
