Help in understanding the tasklets

Help in understanding the tasklets

[Hari LKML]

After reading some of the books and the codes here is my understanding
about the tasklet_action function

the function statrs some thing like this

1. If the tasklet is not running in another processor set the Bit
TASKLET_STATE_RUN;     <<if (tasklet_trylock(t))>>
2. clear the TASKLET_STATE_SCHED bit;       <<if (!test_and_clear_bit(TASKLET_
STATE_SCHED, &t->state))>>
3. start the tasklet     <<(    t->func(t->data))>>


Now when the tasklets function is running and the same interrupt is
raised again but now handled by a different processor (in a SMP
system) the tasklet is now scheduled in a different processor (because
the TASKLET_STATE_SCHED is already cleared in step 2)
and there are every chance of the same type of  taklet running
concurently in different processors thus braking the promise that same
types of tasklets do not ever run simultaniously.

I think i have misunderstood one or the other concept so please
correct me and help me in understanding the Linux Kernel code more
clearly.


Please personally CC me all answers/comments posted to the list, to my
mail id hari.lkml@gmail.com.

Hari

Re: Help in understanding the tasklets

[Jiri Slaby]

On 06/19/2010 08:36 PM, Hari LKML wrote:
> After reading some of the books and the codes here is my understanding
> about the tasklet_action function
> 
> the function statrs some thing like this
> 
> 1. If the tasklet is not running in another processor set the Bit
> TASKLET_STATE_RUN;     <<if (tasklet_trylock(t))>>
> 2. clear the TASKLET_STATE_SCHED bit;       <<if (!test_and_clear_bit(TASKLET_
> STATE_SCHED, &t->state))>>
> 3. start the tasklet     <<(    t->func(t->data))>>
> 
> 
> Now when the tasklets function is running and the same interrupt is
> raised again but now handled by a different processor (in a SMP
> system) the tasklet is now scheduled in a different processor (because
> the TASKLET_STATE_SCHED is already cleared in step 2)
> and there are every chance of the same type of  taklet running
> concurently in different processors thus braking the promise that same
> types of tasklets do not ever run simultaniously.
> 
> I think i have misunderstood one or the other concept so please
> correct me and help me in understanding the Linux Kernel code more
> clearly.

But tasklet_trylock will return 0 when t->func is running on another
processor already because of step 1. Thus the tasklet gets to the end of
the tasklet list and is tried again later.

-- 
js