Re: [PATCH for 2.5] preemptible kernel

[george anzinger <george@mvista.com>]

Nigel Gamble wrote:
> 
> On Sat, 31 Mar 2001, george anzinger wrote:
> > I think this should be:
> >                 if (p->has_cpu || p->state & TASK_PREEMPTED)) {
> > to catch tasks that were preempted with other states.
> 
> But the other states are all part of the state change that happens at a
> non-preemtive schedule() point, aren't they, so those tasks are already
> safe to access the data we are protecting.
> 
If your saying that the task's "thinking" about a state change is
sufficient, ok.  The point is that a task changes it state prior to
calling schedule() and then, sometimes, doesn't call schedule and just
changes its state back to running.  Preemption can happen at any of
these times, after all that is what the TASK_PREEMPTED flag is used for.

On a higher level, I think the scanning of the run list to set flags and
counters is a bit off.  If these things need to be counted and kept
track of, the tasks should be doing it "in the moment" not some other
task at some distant time.  For example if what is being protected is a
data structure, a counter could be put in the structure that keeps track
of the number of tasks that are interested in seeing it stay around.  As
I understand the objective of the method being explored, a writer wants
to change the structure, but old readers can continue to use the old
while new readers get the new structure.  The issue then is when to
"garbage collect" the no longer used structures.  It seems to me that
the pointer to the structure can be changed to point to the new one when
the writer has it set up.  Old users continue to use the old.  When they
are done, they decrement the use count.  When the use count goes to
zero, it is time to "garbage collect".  At this time, the "garbage man"
is called (one simple one would be to check if the structure is still
the one a "new" task would get).  Various methods exist for determing
how and if the "garbage man" should be called, but this sort of thing,
IMNSHO, does NOT belong in schedule().

George