I'm using VxWorks 5.5 and pthread library.
In my code I create a task and this task itself several threads and
for diagnosis I monitor states of these threads
and my other VxWorks tasks from target shell by command "i" and I
get entries with task names such as pthr10 ,
pthr11 etc. and their corresponding tid etc.
My questions is : Is there a way to learn where in my source code
creates pthr11 (say pthrx) ?
Regards
May be you can keep a static data structure (an array) associated with
a static counter that will be used to record where in your code the
pthread x has been created? In other words, assign a tag (a number) to
each places where a pthread can be created in your code and increment
the counter each time a creation is done, then store the place tag and
the value of the counter in the array and increment the array's
current index. By looking at the array's content you'll then know
where in your code each pthread has been created.
Hope this helps.
--
PAD
Hİ
Thanks for answer ,I have 2 more questions regarding this subject
1-Can I say that standart POSIX threads has no concept of thread
name , so we need extensions to manage names of thread ? Please see
the link
http://sources.redhat.com/ml/ecos-discuss/2002-06/msg00103.html
2-If there is no requirement for portability , does it have any
advantage of using pthreads over VxWorks tasks. I'm asking this
because AFAIK pthreads help us with in the systems which has no
concept of task scheduling. But since VxWorks already have task
mechanism I don't see any other reason except "portability" to use
pthreads instead of using VxWorks tasks
3-From the point of VxWorks scheduler a thread is same as task , am
I right ? If not can you give the differences
Regards
Thanks
That is correct. The IEEE 1003.1-2004 standard does not offer any way
of giving threads a name. This means that doing so is left to the
POSIX implementation. VxWorks gives a default name ending with a
continuously incremented counter value, other OS may do differently.
In one of the VxWorks 6.x releases a pair of API (pthread_attr_setname
() and pthread_attr_getname()) has been introduced to let users set
different names. These are extensions to POSIX.
> 2-If there is no requirement for portability , does it have any
> advantage of using pthreads over VxWorks tasks.
Portability is really the main reason for using POSIX threads on
VxWorks. This said there are some interesting constructs like
condition variables, thread specific data, mutex priority ceiling that
are readily available with pthreads. Also starting with the version
6.4 of VxWorks POSIX threads used in real time processes (user-mode
applications, not kernel applications) benefit from the conformance to
the PSE52 profile of IEEE Std 1003.13-2003, in particular the
scheduling of threads can be different on a thread by thread basis. In
VxWorks 5.5 however the pthread implementation is more limited and,
unless you are specifically interested in some of the constructs I
mentioned above, directly using VxWorks tasks is likely to be a better
choice when there is no portability concerns.
> 3-From the point of VxWorks scheduler a thread is same as task , am
> I right ? If not can you give the differences
In VxWorks a POSIX thread is implemented "on top" of a task. In
VxWorks 5.5 there is essentially no difference between threads and
tasks beside the fact that pthread can use the pthread API when
VxWorks tasks should not (they mostly can but there is no good reason
for them to do so). The VxWorks 5.5 scheduler in particular makes no
difference between pthread and vxWorks tasks.
Cheers,
--
PAD