I noticed that based on this, Linux reuses the thread ids of terminated threads instead of generating new ones. For some reason, I need to avoid this behavior. How can I make sure that newly created threads, will have a freshly generated thread id instead of reusing the old ones?
(Update for interested people: I'm working on a DNN scheduler for GPU using PyTorch's C++ API, I need to create a new thread to call each layer/operation, and whenever the newly created thread shares the thread id with a terminated thread, I get CUDNN_STATUS_MAPPING_ERROR. I have reached this after a long time and if I can create threads with unique ids, I might be able to track down the main reason behind this.)
Update 2: POSIX Thread avoids generating new thread ids (thread objects in glibc implementation) as long as there are terminated threads to reuse, I want to avoid this behavior. Maybe somehow deallocating terminated thread would solve this problem. But I don't know how.
Update 3: Based on lines 84-97 in link, Linux tends to reuse previously allocated but terminated threads. Is it somehow possible to deallocate these threads to prevent from reusing previous thread ids?
There would be a way to avoid the stack allocation for terminated threads to be reused, you will have to self-allocate the stack memories. The pthread_attr_setstack could help. Notice that it add complexity to handle the buffer overflowed and the responsibilities now belong to API users
Following is some tests that I have made by play arround the POSIX thread library
Created thread id: 139938008069888 in __pthread_create_2
Created thread id: 139937999677184 in __pthread_create_2
Created thread id: 139937999677184 in __pthread_create_2
Created thread id: 139938008069888 in __pthread_create_2
Thread 1 : db42f700
Thread 2 : dac2e700
Thread 3 : dac2e700
Thread 4 : db42f700
As result, the stack is preserved for thread 3,4
With the self-allocated stack
Created thread id: 139891916830464 in __pthread_create_2
Set stackaddr to 139891916849184
Set stacksize to 32768
Created thread id: 139891916879616 in __pthread_create_2
Set stackaddr to 139891916898352
Set stacksize to 32768
Created thread id: 139891916928768 in __pthread_create_2
Set stackaddr to 139891916947520
Set stacksize to 32768
Created thread id: 139891916977984 in __pthread_create_2
Thread 1 : 139891916830464
Thread 2 : 139891916879616
Thread 3 : 139891916928768
Thread 4 : 139891916977984
Related
I have a Macos application that is crashing, I'm trying to analyze the crash report and I see that a certain thread is the one that keeps on crashing in all of the reports.
Trying to associate that thread to my application thread, the report shows threads numbers (0 as main thread, thread 1, 2 and so on)
and they are totally different number from the thread ID I get from pthread_self / pthread_threadid_np
Anyway to connet between these number so I can find the problematic thread in my app ?
Thanks!
I know it is possible to get the id of a thread by using GetCurrentThreadId(), however, is it possible to actually set the thread id? If so, how?
Ex: I want to change the thread ID of a thread from 5432 to 1234.
The ThreadID is assigned by Windows from internal tables. You cannot change it.
As stated in the documentation
Until the thread terminates, the thread identifier uniquely identifies the thread throughout the system.
If thread ID modification would be possible, then you should disable creating new threads until you ensure that your ID is not used by anyone else. You will admit that is not realistic.
Background:
I have two GUI threads: Main and SendEmail in an MFC/Win32 application.
Normally, the main thread spawns the send email thread and continues to run. The send email thread tells the main thread's window to stay disabled and captures the mouse, and when it exits, it enables the main thread's window and releases the mouse.
This gives the user the work-flow of the main application is disabled while they're sending an email. The need to do this in a separate thread has to do with problems with MAPI and Outlook since 2010, where it would lock up the app if it was executed on the main thread.
However, if it so happens that the main application does exit while the send mail thread is still running, the process crashes (the send mail thread tries to enable the main thread's window which no longer exists...)
Goal:
To have the main thread wait for the send mail thread to terminate before terminating
Sticking point:
Currently, the email thread self-destructs (there is no memory management, since it calls delete on itself when its run method finishes). But I want the main thread to keep a reference to this thread so that it can wait on a live one at exit.
I cannot use a weak reference, I don't think, because the main thread really should wait on this thread object (threads are inherently waitable), so I don't want the object that represents this thread to self-destruct while the min thread holds it.
I can use a shared pointer - so that both the application and the running thread effectively keep the thread object alive... but then how to delete the application's copy of the thread object when the thread is finished? (I don't want the thread object to keep on existing for no purpose).
I could post a message from the email thread to the main app thread saying "I'm dying" so that the main thread immediately waits for the thread to terminate and then deletes its reference...
Any better ideas?
I am a newbee to linux. Right now I am following "Advanced Linux book"
I know when we create a new thread from a process, it gets inherited from the main thread of the process.
Let's say I created a thread pt1 from pt. Then pt1 inherits the environment,code,signal mask.
The only thing that it doesn't share is "set of pending of signals" for the new thread is cleared.
I want to know what more attributes are not shared between the threads of the same process.
Any help is thankful
Threads in the same process share:
Process instructions
Most data
open files (descriptors)
signals and signal handlers
current working directory
User and group id
Each thread has a unique:
Thread ID
set of registers, stack pointer
stack for local variables, return addresses
signal mask
priority
I have a problem in a multi threaded program. My program has 4 threads that are always here.
We will name these thread from 1 to 4.
The goal for my program is to communicate on a socket with a peripheral.
Thread number 4 is used to send the messages to the peripheral.
Each time a message is sent to the peripheral, I use :
pthread_create(&m_hThreadMsgReader, NULL, &ThreadMsgReader, (void*) &argStruct);
This will create a thread to listen to the response on the socket, this thread will return when the socket doesn't contain anymore message : ie
ifiRet = recv(m_iSocket, pcRecBuf, DEFAULT_READ_DATA_LEN, 0); makes iRet take the value 0.
So with the current implementation, a data pooling is made (every minute) on the peripheral (aside from other command sent via user input).
The problem here is that after a few hours, pthread create will crash with an error 11. I've seen on stack overflow that it means that the system might not have enough resources or too many threads.
But I don't understand as in QtCreator debug, i can only see the thread from 1 to 4. I know I might have created like 300 threads, but the list of thread only contains 4, which means all other threads were terminated.
So I don't really understand if the maximum number of thread creation is during the whole lifetime of the process or the number of thread present at the same time.
Should I just find a way to have a single thread for the listening even if it will listen on a empty socket ? Is my implementation a bad pattern ?
You should call pthread_join to free the resources acquired. Or you can use attribute PTHREAD_CREATE_DETACHED in that case you'll not require to use pthread_join