Sharing the timeslice - Linux

This is a discussion on Sharing the timeslice - Linux ; Hi, Consider 3 processes (p1, p2 and p3) Consider that the process p1 has 2 threads ( t1, t2) and lets assume that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for every process by ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Sharing the timeslice

  1. Sharing the timeslice

    Hi,

    Consider 3 processes (p1, p2 and p3)
    Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    every process by RR(round-robin) is 5 ms.
    In the above scenario, When will the p2 start to execute ?

    That is, Will it follow any of the below sequence of execution ?

    1) t1,t2,p2,p3,t1,t2,p2,p3
    (t1 and t2 are executed first in the place of p1 and followed by the
    execution of p2,p3)
    Sharing the timeslice of 5ms allocated to p1 among the threads t1 and
    t2 (like, 2.5ms for t1 and 2.5ms for t2). Any ideas/links ?
    Is it possible to allocate 3ms for t1 and 2ms for t2 ? Any links that
    talk in detail about these scheme ?
    Or
    2) t1,p2,p3,t2,p2,p3,t1,p2,p3
    (t1 is executed during the first cycle of RR and t2 is executed in the
    consecutive cycle of RR and so on..)
    I think, this causes delay in the execution of t2 .
    Or
    3) t1,p2,p3,t1,p2,p3,t1,p2,p3,t2,p2,p3,t2,p2,p3
    (t1 is executed in first cycle of RR and in the consecutive cycles
    also , until the t1 is finished. And after finishing t1, it moves to
    execute the t2)
    I think, this method will not be followed as it would lead to
    starvation of thread t2.

    I use Redhat 9.0 (linux).
    Is there any link that explains about the scheduling between the
    threads in a process with clear illustrations ?

    Thx in advans,
    Karthik Balaguru

  2. Re: Sharing the timeslice

    karthikbalaguru wrote:
    > Hi,
    >
    > Consider 3 processes (p1, p2 and p3)


    You DO realise where you've posted don't you?
    COLA is the last place you'd want to post for this kind of detailed
    technical info...

    Try comp.os.linux.development.system or its sister group, development.apps.

    > I use Redhat 9.0 (linux).
    > Is there any link that explains about the scheduling between the
    > threads in a process with clear illustrations ?


    Errr... Well, the kernel documentation's fairly thorough in many areas...
    And the scheduler source itself is commented.
    One thing though...

    Redhat 9? That must be getting onto at least 5 years out of date by now.

    Consider upgrading to a new distro. For one thing, new kernels have
    different schedulers you can choose from, including a fully pre-emptive one
    and a real-time one, so if one doesn't suit your needs, another might.

    --
    | spike1@freenet.co.uk | |
    | Andrew Halliwell BSc | "ARSE! GERLS!! DRINK! DRINK! DRINK!!!" |
    | in | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! |
    | Computer Science | - Father Jack in "Father Ted" |

  3. Re: Sharing the timeslice

    * karthikbalaguru peremptorily fired off this memo:
    >
    > Consider 3 processes (p1, p2 and p3)
    > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    > every process by RR(round-robin) is 5 ms.
    > In the above scenario, When will the p2 start to execute ?
    >
    > That is, Will it follow any of the below sequence of execution ?
    >
    > 1) t1,t2,p2,p3,t1,t2,p2,p3


    I don't think there is any way of determining (predicting) what runs in
    what order, in general.

    > I use Redhat 9.0 (linux).
    > Is there any link that explains about the scheduling between the
    > threads in a process with clear illustrations ?


    Start with "man pthread_attr_init" and "man sched_setscheduler".

    --
    DOS is ugly and interferes with users' experience.
    -- Bill Gates

  4. Re: Sharing the timeslice

    On May 20, 9:35 pm, Linonut wrote:
    > * karthikbalaguru peremptorily fired off this memo:
    >
    >
    >
    > > Consider 3 processes (p1, p2 and p3)
    > > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    > > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    > > every process by RR(round-robin) is 5 ms.
    > > In the above scenario, When will the p2 start to execute ?

    >
    > > That is, Will it follow any of the below sequence of execution ?

    >
    > > 1) t1,t2,p2,p3,t1,t2,p2,p3

    >
    > I don't think there is any way of determining (predicting) what runs in
    > what order, in general.


    But, Why is not possible to predict the order of execution ?

    I am interested to know if the following happens (assuming p2 takes
    25ms and p3 takes 30ms) -
    t1,t2,p2,p3,t1,t2,p2,p3,t1,p2,p3,p2,p3,p2,p3,p3

    Thx in advans,
    Karthik Balaguru

  5. Re: Sharing the timeslice

    karthikbalaguru writes:

    > On May 20, 9:35 pm, Linonut wrote:
    >> * karthikbalaguru peremptorily fired off this memo:
    >>
    >>
    >>
    >> > Consider 3 processes (p1, p2 and p3)
    >> > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    >> > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    >> > every process by RR(round-robin) is 5 ms.
    >> > In the above scenario, When will the p2 start to execute ?

    >>
    >> > That is, Will it follow any of the below sequence of execution ?

    >>
    >> > 1) t1,t2,p2,p3,t1,t2,p2,p3

    >>
    >> I don't think there is any way of determining (predicting) what runs in
    >> what order, in general.

    >
    > But, Why is not possible to predict the order of execution ?
    >
    > I am interested to know if the following happens (assuming p2 takes
    > 25ms and p3 takes 30ms) -
    > t1,t2,p2,p3,t1,t2,p2,p3,t1,p2,p3,p2,p3,p2,p3,p3
    >
    > Thx in advans,
    > Karthik Balaguru


    Because it is dependant on other system load.

    --
    This year with the release of XP, they are actually behind. The end days
    are near for the BIOS reading inferior OS. It is inevitable.
    comp.os.linux.advocacy - where they put the lunacy in advocacy

  6. Re: Sharing the timeslice

    On May 20, 9:50 pm, Hadron wrote:
    > karthikbalaguru writes:
    > > On May 20, 9:35 pm, Linonut wrote:
    > >> * karthikbalaguru peremptorily fired off this memo:

    >
    > >> > Consider 3 processes (p1, p2 and p3)
    > >> > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    > >> > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    > >> > every process by RR(round-robin) is 5 ms.
    > >> > In the above scenario, When will the p2 start to execute ?

    >
    > >> > That is, Will it follow any of the below sequence of execution ?

    >
    > >> > 1) t1,t2,p2,p3,t1,t2,p2,p3

    >
    > >> I don't think there is any way of determining (predicting) what runs in
    > >> what order, in general.

    >
    > > But, Why is not possible to predict the order of execution ?

    >
    > > I am interested to know if the following happens (assuming p2 takes
    > > 25ms and p3 takes 30ms) -
    > > t1,t2,p2,p3,t1,t2,p2,p3,t1,p2,p3,p2,p3,p2,p3,p3

    >
    > > Thx in advans,
    > > Karthik Balaguru

    >
    > Because it is dependant on other system load.
    >


    But, How does system load impact the below scenario ?

    There are 3 processes (p1, p2 and p3). Here, p2 takes 25ms
    and p3 takes 30ms. The process p1 takes 25ms.
    But, the process p1 has 2 threads ( t1, t2) and t1 takes 15 ms
    and t2 takes 10 ms. The timeslice allocated for every process
    by SCHED_RR(round-robin) is 5 ms.

    Thx in advans,
    Karthik Balaguru

  7. Re: Sharing the timeslice

    karthikbalaguru writes:

    > On May 20, 9:50 pm, Hadron wrote:
    >> karthikbalaguru writes:
    >> > On May 20, 9:35 pm, Linonut wrote:
    >> >> * karthikbalaguru peremptorily fired off this memo:

    >>
    >> >> > Consider 3 processes (p1, p2 and p3)
    >> >> > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    >> >> > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    >> >> > every process by RR(round-robin) is 5 ms.
    >> >> > In the above scenario, When will the p2 start to execute ?

    >>
    >> >> > That is, Will it follow any of the below sequence of execution ?

    >>
    >> >> > 1) t1,t2,p2,p3,t1,t2,p2,p3

    >>
    >> >> I don't think there is any way of determining (predicting) what runs in
    >> >> what order, in general.

    >>
    >> > But, Why is not possible to predict the order of execution ?

    >>
    >> > I am interested to know if the following happens (assuming p2 takes
    >> > 25ms and p3 takes 30ms) -
    >> > t1,t2,p2,p3,t1,t2,p2,p3,t1,p2,p3,p2,p3,p2,p3,p3

    >>
    >> > Thx in advans,
    >> > Karthik Balaguru

    >>
    >> Because it is dependant on other system load.
    >>

    >
    > But, How does system load impact the below scenario ?


    You tell me. What is 25ms here? Real time? CPU time? What. You should
    really take this to the correct newsgroups as indicated by Andrew
    Halliwell. Kernel scheduling is neither simple nor on topic here. This
    is a Microsoft hate group ...

    >
    > There are 3 processes (p1, p2 and p3). Here, p2 takes 25ms
    > and p3 takes 30ms. The process p1 takes 25ms.
    > But, the process p1 has 2 threads ( t1, t2) and t1 takes 15 ms
    > and t2 takes 10 ms. The timeslice allocated for every process
    > by SCHED_RR(round-robin) is 5 ms.
    >
    > Thx in advans,
    > Karthik Balaguru



  8. Re: Sharing the timeslice

    In article <1250f088-4684-4f9b-9253-4ee8784fd4f7
    @w1g2000prd.googlegroups.com>, karthikbalaguru says...
    > On May 20, 9:35 pm, Linonut wrote:
    > > * karthikbalaguru peremptorily fired off this memo:
    > >
    > >
    > >
    > > > Consider 3 processes (p1, p2 and p3)
    > > > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    > > > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    > > > every process by RR(round-robin) is 5 ms.
    > > > In the above scenario, When will the p2 start to execute ?

    > >
    > > > That is, Will it follow any of the below sequence of execution ?

    > >
    > > > 1) t1,t2,p2,p3,t1,t2,p2,p3

    > >
    > > I don't think there is any way of determining (predicting) what runs in
    > > what order, in general.

    >
    > But, Why is not possible to predict the order of execution ?
    >
    > I am interested to know if the following happens (assuming p2 takes
    > 25ms and p3 takes 30ms) -
    > t1,t2,p2,p3,t1,t2,p2,p3,t1,p2,p3,p2,p3,p2,p3,p3


    It sounds more like you are looking for some sort of fixed slot
    scheduling rather than round robin.

    Robert
    ** Posted from http://www.teranews.com **

  9. Re: Sharing the timeslice

    On Tue, 20 May 2008 07:31:09 -0700 (PDT), karthikbalaguru
    wrote:

    >
    >Consider 3 processes (p1, p2 and p3)
    >Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    >that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    >every process by RR(round-robin) is 5 ms.
    >In the above scenario, When will the p2 start to execute ?


    Why do you want to know this ?

    If you _need_ a specific thread execution order, you should proper
    synchronization and usually also priority level based scheduling.
    Trying to use round robin at a single priority level is not going to
    give any predictable result.

    Paul


  10. Re: Sharing the timeslice

    On May 20, 7:31*pm, karthikbalaguru
    wrote:
    > Hi,
    >
    > Consider 3 processes (p1, p2 and p3)
    > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    > every process by RR(round-robin) is 5 ms.
    > In the above scenario, When will the p2 start to execute ?
    >
    > That is, Will it follow any of the below sequence of execution ?
    >
    > 1) t1,t2,p2,p3,t1,t2,p2,p3
    > (t1 and t2 are executed first in the place of p1 and followed by the
    > execution of p2,p3)
    > Sharing the timeslice of 5ms allocated to p1 among the threads t1 and
    > t2 (like, 2.5ms for t1 and 2.5ms for t2). Any ideas/links ?
    > Is it possible to allocate 3ms for t1 and 2ms for t2 ? Any links that
    > talk in detail about these scheme ?
    > Or
    > 2) t1,p2,p3,t2,p2,p3,t1,p2,p3
    > (t1 is executed during the first cycle of RR and t2 is executed in the
    > consecutive cycle of RR and so on..)
    > I think, this causes delay in the execution of t2 .
    > Or
    > 3) t1,p2,p3,t1,p2,p3,t1,p2,p3,t2,p2,p3,t2,p2,p3
    > (t1 is executed in first cycle of RR and in the consecutive cycles
    > also , until the t1 is finished. And after finishing t1, it moves to
    > execute the t2)
    > I think, this method will not be followed as it would lead to
    > starvation of thread t2.
    >
    > I use Redhat 9.0 (linux).
    > Is there any link that explains about the scheduling between the
    > threads in a process with clear illustrations ?
    >
    > Thx in advans,
    > Karthik Balaguru


    Hi,
    While what other experts suggested here is valid,why not try adding
    printfs in every thread to see which sequence it executes.You can
    create a sample program to emulate the scenerio of your
    project.Simulators will come handy though am not sure whether redhat
    has any simulators for your target.Adding printfs can give you
    sequence of execution though there may be delays from the timing
    aspect.

    Regards,
    s.subbarayan

  11. Re: Sharing the timeslice

    On May 21, 9:48 am, ssubbarayan wrote:
    > On May 20, 7:31 pm, karthikbalaguru
    > wrote:
    >
    >
    >
    > > Hi,

    >
    > > Consider 3 processes (p1, p2 and p3)
    > > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    > > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    > > every process by RR(round-robin) is 5 ms.
    > > In the above scenario, When will the p2 start to execute ?

    >
    > > That is, Will it follow any of the below sequence of execution ?

    >
    > > 1) t1,t2,p2,p3,t1,t2,p2,p3
    > > (t1 and t2 are executed first in the place of p1 and followed by the
    > > execution of p2,p3)
    > > Sharing the timeslice of 5ms allocated to p1 among the threads t1 and
    > > t2 (like, 2.5ms for t1 and 2.5ms for t2). Any ideas/links ?
    > > Is it possible to allocate 3ms for t1 and 2ms for t2 ? Any links that
    > > talk in detail about these scheme ?
    > > Or
    > > 2) t1,p2,p3,t2,p2,p3,t1,p2,p3
    > > (t1 is executed during the first cycle of RR and t2 is executed in the
    > > consecutive cycle of RR and so on..)
    > > I think, this causes delay in the execution of t2 .
    > > Or
    > > 3) t1,p2,p3,t1,p2,p3,t1,p2,p3,t2,p2,p3,t2,p2,p3
    > > (t1 is executed in first cycle of RR and in the consecutive cycles
    > > also , until the t1 is finished. And after finishing t1, it moves to
    > > execute the t2)
    > > I think, this method will not be followed as it would lead to
    > > starvation of thread t2.

    >
    > > I use Redhat 9.0 (linux).
    > > Is there any link that explains about the scheduling between the
    > > threads in a process with clear illustrations ?

    >
    > > Thx in advans,
    > > Karthik Balaguru

    >
    > Hi,
    > While what other experts suggested here is valid,why not try adding
    > printfs in every thread to see which sequence it executes.You can
    > create a sample program to emulate the scenerio of your
    > project.Simulators will come handy though am not sure whether redhat
    > has any simulators for your target.Adding printfs can give you
    > sequence of execution though there may be delays from the timing
    > aspect.
    >


    Ok, i am not willing to predict the sequence of execution.

    Can you let me know whether the threads created for a process
    share the timeslice of the process OR the threads created
    are treated like process (have the same timeslice as that of the
    process).

    That is,
    P1 = 5ms will be now t1=5ms and t2=5ms ?
    OR
    P1 =5ms will be now t1 = 2.5ms and t2 = 2.5ms ?

    I am interested in knowing how the threads created by a process
    will be handled by the scheduler.

    Thx in advans,
    Karthik Balaguru

  12. Re: Sharing the timeslice

    * karthikbalaguru peremptorily fired off this memo:

    > On May 20, 9:35 pm, Linonut wrote:
    >> * karthikbalaguru peremptorily fired off this memo:
    >>
    >> > Consider 3 processes (p1, p2 and p3)
    >> > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    >> > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    >> > every process by RR(round-robin) is 5 ms.
    >> > In the above scenario, When will the p2 start to execute ?

    >>
    >> > That is, Will it follow any of the below sequence of execution ?

    >>
    >> > 1) t1,t2,p2,p3,t1,t2,p2,p3

    >>
    >> I don't think there is any way of determining (predicting) what runs in
    >> what order, in general.

    >
    > But, Why is not possible to predict the order of execution ?


    Too many variables. Probably even if you know the scheduler's exact
    algorithm for thread selection.

    But, rather than rely on me coming up with some definitive statement:

    1. Check out the book "Linux Kernel Development", 2nd edition, by
    Robert Love, Novell Press.

    2. Code it up and see how repeatable it is. But be careful -- even
    the small slow-down caused by outputting to the console is enough
    to act as a crude form of synchronization. Furthermore, various
    consoles differ in their speed.

    > I am interested to know if the following happens (assuming p2 takes
    > 25ms and p3 takes 30ms) -
    > t1,t2,p2,p3,t1,t2,p2,p3,t1,p2,p3,p2,p3,p2,p3,p3


    Code it up!

    By the way, if you use the pthreads API, there is a nice pthreads-w32
    port so you can try the same stuff in Windows. (However, the DOS
    console is slow as hell.)

    --
    Microsoft looks at new ideas, they don't evaluate whether the idea will move
    the industry forward, they ask, 'how will it help us sell more copies of
    Windows?'
    -- Bill Gates, The Seattle Weekly, (April 30, 1998)[2]

  13. Re: Sharing the timeslice

    * ssubbarayan peremptorily fired off this memo:

    > While what other experts suggested here is valid,why not try adding
    > printfs in every thread to see which sequence it executes.


    Even those can affect behavior. The tightest would be to write some
    audit info to memory, and then dump it out after the fact.

    > You can
    > create a sample program to emulate the scenerio of your
    > project.Simulators will come handy though am not sure whether redhat
    > has any simulators for your target.Adding printfs can give you
    > sequence of execution though there may be delays from the timing
    > aspect.


    And, if you do use printf(), consider instead using fprintf() and
    trying it with stdout and with stderr. The former is buffered, the
    latter is not. You can also use setvbuf() to change the buffering.

    I'm reworking some old code to synchronize console output, and I'm
    having a hell of time, this time around, getting the console output from
    various threads to intermix (in stderr), so that I can test the
    synchronizer.

    --
    As we look ahead into the next century, leaders will be those who empower
    others.
    -- Bill Gates

  14. Re: Sharing the timeslice

    Linonut writes:

    > * karthikbalaguru peremptorily fired off this memo:
    >
    >> On May 20, 9:35 pm, Linonut wrote:
    >>> * karthikbalaguru peremptorily fired off this memo:
    >>>
    >>> > Consider 3 processes (p1, p2 and p3)
    >>> > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    >>> > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    >>> > every process by RR(round-robin) is 5 ms.
    >>> > In the above scenario, When will the p2 start to execute ?
    >>>
    >>> > That is, Will it follow any of the below sequence of execution ?
    >>>
    >>> > 1) t1,t2,p2,p3,t1,t2,p2,p3
    >>>
    >>> I don't think there is any way of determining (predicting) what runs in
    >>> what order, in general.

    >>
    >> But, Why is not possible to predict the order of execution ?

    >
    > Too many variables. Probably even if you know the scheduler's exact
    > algorithm for thread selection.
    >
    > But, rather than rely on me coming up with some definitive statement:
    >
    > 1. Check out the book "Linux Kernel Development", 2nd edition, by
    > Robert Love, Novell Press.
    >
    > 2. Code it up and see how repeatable it is. But be careful -- even
    > the small slow-down caused by outputting to the console is
    > enough


    Small slow down? Outputting to the console makes a HUGE difference.

  15. Re: Sharing the timeslice

    Linonut writes:

    > * ssubbarayan peremptorily fired off this memo:
    >
    >> While what other experts suggested here is valid,why not try adding
    >> printfs in every thread to see which sequence it executes.

    >
    > Even those can affect behavior. The tightest would be to write some
    > audit info to memory, and then dump it out after the fact.
    >
    >> You can
    >> create a sample program to emulate the scenerio of your
    >> project.Simulators will come handy though am not sure whether redhat
    >> has any simulators for your target.Adding printfs can give you
    >> sequence of execution though there may be delays from the timing
    >> aspect.

    >
    > And, if you do use printf(), consider instead using fprintf() and
    > trying it with stdout and with stderr. The former is buffered, the
    > latter is not. You can also use setvbuf() to change the buffering.
    >
    > I'm reworking some old code to synchronize console output, and I'm
    > having a hell of time, this time around, getting the console output from
    > various threads to intermix (in stderr), so that I can test the
    > synchronizer.


    It should be the simplest thing in the world. A FIFO queue running on
    another thread.

  16. Re: Sharing the timeslice

    On May 21, 4:30*pm, Linonut wrote:
    > * ssubbarayan peremptorily fired off this memo:
    >
    > > While what other experts suggested here is valid,why not try adding
    > > printfs in every thread to see which sequence it executes.

    >
    > Even those can affect behavior. *The tightest would be to write some
    > audit info to memory, and then dump it out after the fact.
    >
    > > You can
    > > create a sample program to emulate the scenerio of your
    > > project.Simulators will come handy though am not sure whether redhat
    > > has any simulators for your target.Adding printfs can give you
    > > sequence of execution though there may be delays from the timing
    > > aspect.

    >
    > And, if you do use printf(), consider instead using fprintf() *and
    > trying it with stdout and with stderr. *The former is buffered, the
    > latter is not. *You can also use setvbuf() to change the buffering.
    >
    > I'm reworking some old code to synchronize console output, and I'm
    > having a hell of time, this time around, getting the console output from
    > various threads to intermix (in stderr), so that I can test the
    > synchronizer.
    >
    > --
    > As we look ahead into the next century, leaders will be those who empower
    > others.
    > * *-- Bill Gates


    Hi,
    We used the technique you suggested to debug one of the crucial
    issues with our project and made good progress.I gave printf
    suggestion just to play around to get a feel of the sequence.If its
    real project,I would try the technique suggested by you then going for
    a printf.

    Regards,
    s.subbarayan

  17. Re: Sharing the timeslice

    * ssubbarayan peremptorily fired off this memo:

    > We used the technique you suggested to debug one of the crucial
    > issues with our project and made good progress.I gave printf
    > suggestion just to play around to get a feel of the sequence.If its
    > real project,I would try the technique suggested by you then going for
    > a printf.


    It's a useful technique, but has its own issues. So I use functions
    that only report errors, unless you elevate the verbosity at run time.

    And, if you want the fastest code, a configure-time switch disables
    those functions completely (converting them to no-op macros).

    By the way, I'm getting the feeling that the latest libc has somehow
    made output to stderr "thread-safe". I can't get two threads to mingle
    their output! I wish I had an older kernel handy.

    I'll have to try it on Windows and see what happens.

    --
    Intellectual property has the shelf life of a banana.
    -- Bill Gates

  18. Re: Sharing the timeslice

    Linonut wrote:
    > Too many variables. Probably even if you know the scheduler's exact
    > algorithm for thread selection.


    Even if you knew the exact algorithm that prolly wouldnt help with a
    modern mutli core cpu.

  19. Re: Sharing the timeslice


    "karthikbalaguru" wrote in message
    news:3f01128c-4b7b-415e-ba77-0d3260bd5fbb@g16g2000pri.googlegroups.com...
    > Hi,
    >
    > Consider 3 processes (p1, p2 and p3)
    > Consider that the process p1 has 2 threads ( t1, t2) and lets assume
    > that t1 takes 15 ms and t2 takes 10 ms. If the timeslice allocated for
    > every process by RR(round-robin) is 5 ms.
    > In the above scenario, When will the p2 start to execute ?
    >
    > That is, Will it follow any of the below sequence of execution ?




    Here's the bottom line. Even if you did figure out what the exact timeslice
    methodology and sequence was, what you would have in the end is a bunch of
    code that makes too many assumptions to be reliable.

    What exactly are you writing where the *exact* sequence of thread execution
    is so important?

    It is a *BIG* mistake to assume the order in which threads will execute.
    What if someone runs this on a quad-core system? Or a machine with 32
    processors? Write generic code that *WORKS* and don't fuss with and make
    assumptions as to what thread will run in what order and for how long. What
    you're trying to do is not portable, not reliable and is NOT guaranteed to
    work across a variety of machines and kernels.

    I can't think of a single valid reason why it is so critical to know the
    exact order of execution. Unless you can explain why something *must* happen
    in some specific order you are just complicating the hell out of this for no
    valid reason. Once again... write generic code that will run properly and
    don't make it machine and kernel specific because no matter what you figure
    out there is basically zero chance that it will work reliably outside of
    your specific development environment.





    ** Posted from http://www.teranews.com **

+ Reply to Thread