RTEMS task names

Applications
1

Hello! I have a curiosity about RTEMS task names,

I want to run a program that iterates through all tasks and gets their names. For tasks/threads that are created via rtems_task_create , it works perfectly, and I can successfully get the name, via rtems_object_get_name(...) but also via pthread_getname_np.

For tasks/threads created via std::thread or pthread_create and later set their names via pthread_setname_np , whenever I iterate through them, pthread_getname_np nor rtems_object_get_name does not work to get their names.

This is ran on version 6.1
My questions are:

  • Are all tasks created in the system, no matter what method (std::thread, pthread_create, rtems_task_create), stored and iterable by rtems_task_iterate?

  • What would be a workaround for the case where a thread’s name is set with pthread_setname_np , should this function simply be replaced with an rtems equivalent that actually works? Thank you so much, any input is more then welcome

2

I have not seen any problems with the librtemscxx support. The implementation to update the attributes shows how I did it.

Does this help?

3

I checked a command I have been making to print the priorities of all threads and in that code I have:

void something(Thread_Control *the_thread) {
  char name[40];
  _Thread_Get_name(the_thread, name, sizeof(name));
  printf("name: %s\n", name);
}

I found this code in the shell’s monitor. Maybe there is no user facing API to get a name?

4

Currently I have found two says to set a thread’s name that work.
A thread created by rtems_task_create has it’s name set at the call point and it is successfuly found by the Thread Create User Extension

The second method is creating a thread with pthread_create and later setting it’s name with rtems_object_set_name(thread, name). Althought this successfuly sets the thread’s name to name, the Thread Create User Extension fails to get the thread’s intended name. This happens because this method has 2 lines of code.
1st: Creates the thread
(between the two lines): The Thread Create User extension is called and tries to get the thread name
2nd: The thread name is set via rtems_object_set_name.

I looked over the librtemscxx code you set that looks like it sets some thread attributes (I am not too experience so forgive me if I dont properly understand what you sent), but it looks like those are attributes for rtems created task. I made sure to look over pthread_attr_t and it doesn’t look like you can specify a name there…

To me it looks like I want to achieve isn’t really possible in the way I want it, for any method that a thread is created rtems_task_create/pthread_create to have the thread create user extension get it’s intended name, as for the pthread_create method, the user extension is simply called too early, but is the correct behaviour for the user extension.

I think my only option now that I understand what the issues were, is to simply find a new method in which I can get their intended names.

A good takeaway from this discussion aside all the information exchanged should be that, from the looks of it
pthread_setname_np does not work. and
pthread_getname_np works.

Which is… wierd maybe, I don’t know if anything should be done about it or not. The documentation does not specify support for those functions anyways so perhaps nothing has to be done

5

The calls pthread_setname_np and pthread_getname_np do work. I have them working in the librtemscxx. They cannot not work in a thread create user extension because the extension call will happen during the pthread create call and before you can set the thread name.

Did you run the shell task or pthread commands in a shell to see what they show?

LibBSD names RTEMS threads but this also happens after the thread is created.

And to let you know librtemscxx provides a C++ way to give C++ std thread attributes such as priority and stack size.

6

@kiwichris There are public APIs to get the name of a thread or other object. pthread_getname_np() and rtems_object_get_name. There are also set versions of those.

You could not use any API expecting a thread/task ID during the create extension for at least two reasons. First, the object is not “open” in the sense that it is not fully created and the ID is not “published” via the local table of that API class. Second, user extensions are invoked inside the OS at varying levels of criitical section locking. Calling an API that assumes it is outside the OS isn’t guaranteed to be safe.

The thread has to be fully created before you can set name on it. Further the name is either a string or 32-bit value based on the API used to create it. Classic API objects always have 32-bit value names. POSIX threads really do not have names per POSIX so strings it is in Linux, FreeBSD, and RTEMS.

From a user create extension, the task control block may be initialised enough to call _Thread_Set_name(). That’s the internal method which takes a TCB *.

7

Thanks for the link. I did not know it existed. I think the monitor commands should be updated to use this call.