[lkml]   [2002]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Developing multi-threading applications

    >Depending by the applications. With my simulation/emulation program I need
    >to create
    >many thread because each thread resolve/manage/compute a specific problem
    >it's live depend by some factors. Each thread is create only if needed to
    >avoid the
    >overhead. The simulation/emulation is a "merge" of many and many object,
    >each object
    >work to resolve/manage/compute a specific problem. All the low objects are
    >grouped to
    >resolve a specific problem and are managed by a thread controller that
    >should take some
    >decision or doing some work. Some thread controller are grouped and managed
    >by another
    >thread controller and so on. Do not think that I need always 400 threads
    >active they are
    >create only if need by the controller. You must thinks this
    >simulation/emulation as collection
    >of many and many object that should interoperate, and the model is designed
    >to scale easily
    >on a distribuite environment.

    If it's a simulation, you don't *really* need the threads, you just need to
    be able to act as if you had them. After all, what are you simulating if what
    work gets done when is up to the random vagaries of the OS scheduler?

    If it's a real application wanting real performance, the suggestions I made
    stand -- you don't want many more threads working than you have CPUs and you
    don't want a lot of threads sitting around waiting for work (and thus forcing
    bazillions of extra context switches).

    It sounds to me like your design is broken, needlessly mapping threads to
    I/Os that are being waited for one-to-one. This is a common error among
    programmers who consciously or subconsciously have accepted the 'more threads
    can do more work' philosophy.

    What you need to do is take whatever it is you're thinking of as a 'thread'
    right now, which I'd roughly define as 'one logical task, from start to
    completion' and realize that there is absolutely no reason to map this
    one-to-one to actual pthreads threads and every reason in the world not to.

    This will conserve resources (12 thread stacks instead of 300, 12 KSEs
    instead of 300), reduce context switches (context switches will only occur
    when there's no work to do at all or a thread uses up its entire timeslice
    rather than every time we change which client/task we're doing work for/on),
    improve scheduler efficiency (because the number of ready threads will not
    exceed the number of CPUs by much) and more often than not, clean up a lot of
    ugliness in your architecture (because threads are probably being used
    instead of a sane abstraction for 'work to be done' or 'a client I'm doing
    work for').


    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:26    [W:0.027 / U:52.912 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site