[lkml]   [2001]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH for 2.5] preemptible kernel
    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().

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:22    [W:0.021 / U:47.176 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site