On 4/20/07, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi Pradeep....
> I am using workqueues in my module.
> Since work_struct or delayed_work can be context switch, they can
> sleep and are safe.
Sleep, yes. But safe? You need to elaborate what kind of safety you
refer here...
I meant you can do some work which can sleep without any
worries.Apologies for not being clear.
> So does this means i need to serialize my work handler function
> between work events manually?
>
Well, if you need to protect some shared structures or variables, then
probably you need serialization. or perhaps you can construct a lock
free algorithm..
> e.g
>
> static void work_handler(struct work_struct *work)
> {
> /*Do something here*/
>
> unsigned long delay = jiffies + 20;
>
> INIT_DELAYED_WORK(&mydelayedwork, work_handler);
> schedule_delayed_work(mydelaydwork, delay);
/*please include do something here too :)*/
> }
>
> static int my_init(void)
> {
> /*do something*/
> unsigned long delay = jiffies + 20;
>
> INIT_DELAYED_WORK(&mydelayedwork, work_handler);
>
> schedule_delayed_work(mydelaydwork, delay)
> return 0;
> }
>
What I don't know from the above snippet is, how the code flow looks
like? my_init() and then work_handler(), followed by work_handler
queuing itself to the work queue over and over again until certain
condition is met? If that is correct, IMHO you don't need any
serialization (even if you're on SMP).
Ok, that was helpful.
But since work events can be scheduled and can be put to sleep as and
when kernel feels like putting them, why can't then a work event sleep
after intialising the delayed work in work_handler?Please note that
interrupts are very much enabled so our work can be put to sleep
waiting on the workqueue.
So this means there can more than one work events for the same wanting
to run same work handler on the workqueue.Which will run first we have
no way to know, untill we serialize them though using a semaphore i
guess.
I hope i made my doubt clear.
Thanks
~psr
regards,
Mulyadi.
--
play the game
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
