Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

urgent : pthread identification

174 views
Skip to first unread message

tguclu

unread,
Jan 21, 2009, 4:52:49 AM1/21/09
to
Hello

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

PAD

unread,
Jan 21, 2009, 1:51:16 PM1/21/09
to
The default POSIX thread names are simply continually incremented each
time a pthread is created starting from 0. In later versions of
VxWorks an API has been added that allows to set the name of a POSIX
thread instead of using the default one but this is not available in
VxWorks 5.5.

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

tguclu

unread,
Jan 22, 2009, 3:33:42 AM1/22/09
to

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

PAD

unread,
Jan 23, 2009, 1:58:34 PM1/23/09
to

> 1-Can I say that standart POSIX threads has no concept of thread
> name , so we need extensions to manage names of thread ?

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

0 new messages