Query on RTP - VxWorks

This is a discussion on Query on RTP - VxWorks ; Hi to EveryOne, I trying to learn about RTP project . I created a VIP project and ROMFS as its subProject .In that i added one RTP project and i created a template file.Here i written one main task and ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Query on RTP

  1. Query on RTP

    Hi to EveryOne,
    I trying to learn about RTP project . I created a VIP project and
    ROMFS as its subProject .In that i added one RTP project and i created
    a template file.Here i written one main task and in main task i
    created a thread and compiled succesfully.But while spawning my main
    task in simulator i am getting an error " resource unavailable".But if
    i created a task (taskSpawn)instead of thread its working properley.I
    included posix thread support in my vxworks image also.

    One more thing i couldn't call some of the API's also like
    ioGlobalStdSet and also kernel api's like windPwrModeGet().

    Can anyOne give me some suggestions .

  2. Re: Query on RTP

    Hello Senthil,

    How do you get the " resource unavailable" error exactly? Is it a
    message printed on the screen? Is it an errno coming back from an API?
    Also may be you can tell us what VxWorks 6 version you are using?
    Depending on the version different components are required in the
    kernel to support POSIX thread in user space (RTP).

    Regarding what can or cannot be done in RTPs be aware that starting
    with VxWorks 6.0 there are two different execution environments
    supported on VxWorks: the kernel space environment and the user space
    environment. Since the user space environment is meant to provide
    isolation and protection both for what's running in an RTP but also
    for the other RTPs and kernel tasks, not all operations that may be
    done in the kernel environment are allowed (i.e. supported) in the
    user space environment.

    Regarding ioGlobalStdSet() although this API is not supported in the
    user space you can take advantage of the inheritance concept built in
    the RTP model: an RTP will inherit the standard I/O channels of its
    parent. Note also that the RTPs are meant to be closer to the POSIX
    model than the kernel, so you may be able to use the dup() and dup2()
    API to do want you want to do.

    Regarding windPwrModeGet() may be you could use a monitor task in the
    kernel that would pass the information to a task in the RTP via a
    message queue?

    Hope this helps,


  3. Re: Query on RTP

    I got the "resource unavailable" from pthread_create api

    perror("\nThread creation failed");

    I dont know whats the reason for it.

    In RTP we can't call many of the kernel api's as like application in
    the kernel space.Then how about the performance of RTP process
    comparing to the application tasks running in the kernel space?.

    Thanks for ur suggestions given.

  4. Re: Query on RTP

    Hi Senthil,

    I think your problem with pthread_create() is likely caused by your
    kernel image lacking the pthread scheduler

    Regarding performances, well, it depends on the application so you
    might have to run your own tests to see whether the performance
    difference is acceptable for you. As a general comment, since the
    protection between an RTP and the kernel involves crossing the system
    call boundary, which is a trap-based mechanism, there will be a
    penalty each time this boundary is crossed by the user-side tasks. If
    the application does not require doing many system calls then the
    overhead is minimal. If the application heavily requires to do system
    calls then the overhead might become noticeable. Memory context
    switching is not so much an issue because RTPs already have the kernel
    pages in their own context (but they don't have the right to access
    them) so crossing the system call boundary does not involve a context
    switch. Also, although a memory context switch does occur when a
    kernel task is scheduled after a user-side task that is not a costly
    operation since VxWorks has a flat memory model (i.e. no address range



+ Reply to Thread