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,

--
PAD

hi
I got the "resource unavailable" from pthread_create api

if(pthread_create(&thr1,NULL,(void*)func,arg)
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.

Hi Senthil,

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

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
overlapping).

Cheers,

--
PAD