Did you know that beginning with the 7.1 release, you can name the secondary threads you create in a process? Prior to 7.1, the system assigned a thread ID and there was no interface to specify a thread name. However, thread IDs can be difficult to work with, particularly when doing problem determination, because the IDs provide no indication of what that thread is for. You’d have to go in through the work management interfaces to display each thread and examine its call stack to have some idea of what that thread may be doing.
Likewise, the synchronization mechanisms commonly used in multi-threaded applications–mutexes, condition variables, and read/write locks–couldn’t be managed by names prior to 7.1; name support was also added for these in the 7.1 release.
Of course, the documentation in the IBM i Knowledge Center doesn’t exactly tell you this; you must do some review of application programming interfaces to find out about this little enhancement.
The work management “Work with Threads” interface that displays thread information (option 20 when using WRKJOB on the green screen) was updated to display the thread name. The thread name isn’t displayed through the IBM Navigator for i Web console. Also, very few of the IBM-supplied multi-threaded processes have taken advantage of using the thread naming capability; probably because these interfaces are not portable.
You can set the name of the target thread with the pthread_setname_np() function.
You can retrieve the name of a thread with the pthread_getname_np() function.
Likewise, there are setname and getname interfaces for mutexes, condition variables, and read/write locks.
pthread_mutex_setname_np()
pthread_mutex_getname_np()
pthread_cond_setname_np()
pthread_cond_getname_np()
pthread_rwlock_setname_np()
pthread_rwlock,getname_np()
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.