When using tasks with and without VX_FP_TASK concurrently , Whathappen in the context swithcing? - VxWorks

This is a discussion on When using tasks with and without VX_FP_TASK concurrently , Whathappen in the context swithcing? - VxWorks ; Hello, In my project, I found a issue that the management of fpp register is corrupted by context switching when running tasks with and without VX_FP_TASK concurrently. the property of problem task is like below A Task : priority 90 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: When using tasks with and without VX_FP_TASK concurrently , Whathappen in the context swithcing?

  1. When using tasks with and without VX_FP_TASK concurrently , Whathappen in the context swithcing?

    Hello,


    In my project, I found a issue that the management of fpp register is
    corrupted by context switching when running tasks with and without
    VX_FP_TASK concurrently.

    the property of problem task is like below
    A Task : priority 90 without VX_FP_TASK
    FOREVER {
    float f = 0.0;
    f += 1.0;
    taskDelay(1);
    }

    B Task : priority 100 with VX_FP_TASK
    FOREVER {
    float f1 = 0.0;

    ....

    f1 += 1.0;

    taskDelay(10);
    }

    Of course, the solution of the problem is to add A task VX_FP_TASK
    option.
    -----------------------------------------------------------------
    | But, I don't know why the problem is happen. |
    -----------------------------------------------------------------

    when context switching happens, all float point register is saved if
    using VX_FP_TASK. and when coming back, the saved register is
    restored.
    so, even if there is a task which don't have VX_FP_TASK by mistake,
    the task with VX_FP_TASK should be independent with other task.

    Could you tell me why the problem is happen?

    Thank you for reading







  2. Re: When using tasks with and without VX_FP_TASK concurrently , Whathappen in the context swithcing?

    Essentially this is what is happening.

    Floating point operations use the floating point register set. When
    VxWorks has to save the registers for a context switch, it does not
    save the floating point registers unless explicitly told to. One
    tells it to save the floating point registers by using the VX_FP_TASK
    option when the task is created.

    What is occuring? Simple. Your floating point registers are getting
    clobbered by another task that uses floating point operations.

    Why does VxWorks do things this way? Not everyone needs floating
    point. Thus, if it is not needed, not saving or restoring them is
    supposed to improve the context switching performance.

    Sparky.


    On Sep 13, 7:08*pm, munhoney wrote:
    > Hello,
    >
    > In my project, I found a issue that the management of fpp register is
    > corrupted by context switching when running tasks with and without
    > VX_FP_TASK concurrently.
    >
    > the property of problem task is like below
    > * A Task : priority 90 without VX_FP_TASK
    > * * * *FOREVER {
    > * * * * * *float f = 0.0;
    > * * * * * *f += 1.0;
    > * * * * * *taskDelay(1);
    > * * * }
    >
    > * B Task : priority 100 with VX_FP_TASK
    > * * * * *FOREVER {
    > * * * * * * float f1 = 0.0;
    >
    > * * * * * * ....
    >
    > * * * * * * f1 += 1.0;
    >
    > * * * * * * taskDelay(10);
    > * * * * *}
    >
    > Of course, the solution of the problem is to add A task VX_FP_TASK
    > option.
    > -----------------------------------------------------------------
    > | But, I don't know why the problem is happen. |
    > -----------------------------------------------------------------
    >
    > when context switching happens, all float point register is saved if
    > using VX_FP_TASK. and when coming back, the saved register is
    > restored.
    > so, even if there is a task which *don't have VX_FP_TASK by mistake,
    > the task with VX_FP_TASK should be independent with other task.
    >
    > Could you tell me why the problem is happen?
    >
    > Thank you for reading



  3. Re: When using tasks with and without VX_FP_TASK concurrently , What happen in the context swithcing?

    On 2008-09-14, peter.mitsis@gmail.com wrote:
    > Floating point operations use the floating point register set. When
    > VxWorks has to save the registers for a context switch, it does not
    > save the floating point registers unless explicitly told to. One
    > tells it to save the floating point registers by using the VX_FP_TASK
    > option when the task is created.


    To be a bit more specific here (and I might have it wrong), what causes the
    floating point registers to be saved isn't so much the VX_FP_TASK
    setting of the task it's switching *from*, but of the task it's
    switching *to*. The kernel leaves the floating point registers loaded as
    long as it can because saving them is expensive. If it's switching from
    a floating point task to a non-floating point task, it doesn't have to
    save them because it knows the task its switching to won't be using
    them. They only need to be saved when it switches to another floating-point
    task.

    Disclaimer: I don't know the internals of how vxWorks works, so I could
    be wrong, but a lot of kernels work this way yadda yadda yadda...
    --
    roger ivie
    rivie@ridgenet.net

  4. Re: When using tasks with and without VX_FP_TASK concurrently , What happen in the context swithcing?

    Roger Ivie wrote:

    >On 2008-09-14, peter.mitsis@gmail.com wrote:
    >> Floating point operations use the floating point register set. When
    >> VxWorks has to save the registers for a context switch, it does not
    >> save the floating point registers unless explicitly told to. One
    >> tells it to save the floating point registers by using the VX_FP_TASK
    >> option when the task is created.

    >
    >To be a bit more specific here (and I might have it wrong), what causes the
    >floating point registers to be saved isn't so much the VX_FP_TASK
    >setting of the task it's switching *from*, but of the task it's
    >switching *to*. The kernel leaves the floating point registers loaded as
    >long as it can because saving them is expensive. If it's switching from
    >a floating point task to a non-floating point task, it doesn't have to
    >save them because it knows the task its switching to won't be using
    >them. They only need to be saved when it switches to another floating-point
    >task.
    >
    >Disclaimer: I don't know the internals of how vxWorks works, so I could
    >be wrong, but a lot of kernels work this way yadda yadda yadda...


    You just described "lazy context save", which was pointed out to the OP
    once before.


  5. Re: When using tasks with and without VX_FP_TASK concurrently , Whathappen in the context swithcing?

    On Sep 15, 2:10*am, spammers_...@pandora.orbl.org wrote:
    > Roger Ivie wrote:
    > >On 2008-09-14, peter.mit...@gmail.com wrote:
    > >> Floating point operations use the floating point register set. *When
    > >> VxWorks has to save the registers for a context switch, it does not
    > >> save the floating point registers unless explicitly told to. *One
    > >> tells it to save the floating point registers by using the VX_FP_TASK
    > >> option when the task is created.

    >
    > >To be a bit more specific here (and I might have it wrong), what causes the
    > >floating point registers to be saved isn't so much the VX_FP_TASK
    > >setting of the task it's switching *from*, but of the task it's
    > >switching *to*. The kernel leaves the floating point registers loaded as
    > >long as it can because saving them is expensive. If it's switching from
    > >a floating point task to a non-floating point task, it doesn't have to
    > >save them because it knows the task its switching to won't be using
    > >them. They only need to be saved when it switches to another floating-point
    > >task.

    >
    > >Disclaimer: I don't know the internals of how vxWorks works, so I could
    > >be wrong, but a lot of kernels work this way yadda yadda yadda...

    >
    > You just described "lazy context save", which was pointed out to the OP
    > once before.


    what is "lazy context save"?

    Actually, before knowing the concept, I don't know whether vxWorks
    uses "lazy context save" technique or not.

    and if the lazy context save technique cause the problem, why does not
    windriver fix the problem?


  6. Re: When using tasks with and without VX_FP_TASK concurrently , What happen in the context swithcing?

    On 2008-09-15, munhoney wrote:
    > and if the lazy context save technique cause the problem, why does not
    > windriver fix the problem?


    Lazy context save does not cause the problem. Using floating point
    registers in a task that is not marked as a floating point task causes
    the problem.
    --
    roger ivie
    rivie@ridgenet.net

  7. Re: When using tasks with and without VX_FP_TASK concurrently , Whathappen in the context swithcing?

    On Sep 16, 4:25*am, Roger Ivie wrote:
    > On 2008-09-15, munhoney wrote:
    >
    > > and if the lazy context save technique cause the problem, why does not
    > > windriver fix the problem?

    >
    > Lazy context save does not cause the problem. Using floating point
    > registers in a task that is not marked as a floating point task causes
    > the problem.
    > --
    > roger ivie
    > ri...@ridgenet.net


    Right,

    However, I want to know how the problem happen.
    if windriver implements the context switching perfectly, I think the
    problem does not happen.


  8. Re: When using tasks with and without VX_FP_TASK concurrently , What happen in the context swithcing?

    munhoney wrote:

    >On Sep 16, 4:25*am, Roger Ivie wrote:
    >> On 2008-09-15, munhoney wrote:
    >>
    >> > and if the lazy context save technique cause the problem, why does not
    >> > windriver fix the problem?

    >>
    >> Lazy context save does not cause the problem. Using floating point
    >> registers in a task that is not marked as a floating point task causes
    >> the problem.
    >> --
    >> roger ivie
    >> ri...@ridgenet.net

    >
    >Right,
    >
    >However, I want to know how the problem happen.
    >if windriver implements the context switching perfectly, I think the
    >problem does not happen.


    It works exactly as designed. If you would take the time to learn
    what "lazy context save" is, then you would understand it is
    a performance enhancement. The rule is that all tasks that use
    H/W floating point must set the FP flag. If you don't follow the rules,
    then you will have problems.

    I'm tired of doing your job for you, so this is my last post in this
    thread.

+ Reply to Thread