This question already has answers here:
How to set the name of a thread in Linux pthreads?
(3 answers)
Closed 6 years ago.
I have a multithreaded Linux application written in C/C++. I have chosen names for my threads. To aid debugging, I would like these names to be visible in GDB, "top", etc. Is this possible, and if so how?
(There are plenty of reasons to know the thread name. Right now I want to know which thread is taking up 50% CPU (as reported by 'top'). And when debugging I often need to switch to a different thread - currently I have to do "thread apply all bt" then look through pages of backtrace output to find the right thread).
The Windows solution is here; what's the Linux one?
Posix Threads?
This evidently won't compile, but it will give you an idea of where to go hunting. I'm not even sure its the right PR_ command, but i think it is. It's been a while...
#include <sys/prctl.h>
prctl(PR_SET_NAME,"<null> terminated string",0,0,0)
If you are using a library like ACE the Thread has a way to specify the thread name when creating a new thread.
BSD Unix has also a pthread_set_name_np call.
Otherwise you can use prctl as mentioned by Fusspawn.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 months ago.
Improve this question
I am using Pagmo, a C+ API for my optimization problem. Pagmo launches a new thread when a new optimization is launched, via invocation of island.evolve(). MY point is that I don't have fine-grained control here over the type of thread that's launched "under the hood" of Pagmo. I can query Pagmo threads on their status - as to whether they've completed their run. I have a machine with 28 physical cores and I'm thinking that the optimum number of my running threads would be on the order of 28. Right now, my code just dumps the whole lot of threads onto the machine and that's substantially more than the number of cores - and hence, likely very inefficient.
I'm thinking of using a std::counting_semaphore (C++ 20) and setting the counter to 28. each time I launch a thread in Pagmo, I would decrement the semaphore counter. When it hits 0, the remaining threads would block and wait in the queue until the counter was incremented.
I'm thinking I could run a loop which queried the Pagmo threads as to their statuses and increment the std::counting_semaphore's counter each time a thread went idle (meaning its task was completed). Of course, the Pagmo threads are ultimately joined. Each time the counter goes above 0, a new thread is allowed to start - so I believe.
My questions are:
is the the best practice as to how to limit/throttle the number of running threads using modern C++?
Is there a better way I haven't thought of?
Is there a way to query Linux in real time, as to the number of running threads?
Thanks in advance!
Phil
I had tried a simple loop to launch and throttle theads creation but it didn't prove to work well and threads were launched too quickly.
First of all, your post could use some editing and even perhaps provide a code snippet that would help us understand the problem more. Right now I'm only going through the documentation based on a wild guess of what you are doing there.
I've quickly checked what Pagmo is about and I would at first advise to be careful when limiting any library that is designed for parallel computation, from outside of the library.
I will try to answer your questions:
I do not think that this is the best way to throttle threads created by an external library
Yes, first of all I've checked the Pagmo API documentation and if I understand you correctly you are using an island class - based on what they state in their documentation the default class that inherits island and is constructed by the default ctor is thread_island (at least on non-POSIX systems - which may not be your case). However thread_island can be constructed via the thread_island(bool use_pool) ctor which indicates that you can specify to these island classes a common thread pool which they can use. And if it is done for non-POSIX systems, it is most likely done for POSIX systems as well. So if you wish to limit the number of threads I would do this via a thread pool.
You can limit the maximum number of threads running on linux via /proc/sys/kernel/threads-max, you can also instruct a Linux system to treat some processes with less importance via niceness
Hope it helps!
EDIT: As a foot note I will also mention that the documentation actually encourages the use of thread_island even on POSIX systems. See this link here
EDIT2: In case that you must use fork_island due to their mentioned issues when thread_safety cannot be guaranteed. Then another option would be to limit available resources via setrlimit see this link right here - you are interested in setting RLIMIT_NPROC
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What are the thread limitations when working on Linux compared to processes for network/IO-bound apps?
What is meant by context switches in threads or processes ? Also which is better : Threads or Processes ? I mean which is more space efficient and which is more time efficient ?
Take a look at this answer.
I don't think you can say one is better than the other - it depends what you are doing.
There is a detailed overview of context switches here: http://en.wikipedia.org/wiki/Context_switch
In the most basic sense a context switch is when the processor pauses execution of a task to do another task.
Also, you have to remember that threads may be your only choice if your OS is embedded and doesn't support multiple processes ;)
This question already has answers here:
How can I determine if a Win32 thread has terminated?
(2 answers)
Closed 6 years ago.
Is there a way to get a notification that a thread no longer runs (has returned) in your application?
I know this is possible in kernel mode (using PsSetCreateThreadNotifyRoutine), but is there a way to know this from user mode, using only Win32 API ?
The problem is that I can't control the code in the thread, because my module is part of a library. Making a driver to monitor the system would not be too hard, but it's annoying for the users to install a driver even for a basic application that uses my library.
My code uses TLS storage, and under Linux/Unix pthread_key_create can take a pointer to a function that is called when the thread is destroyed. But TlsAlloc (Windows) has nothing like this...
Thanks in advance!
Depends on what kind of libraray you have. For a DLL could handle the thread termination in your DllMain (DLL_THREAD_DETACH). The MSDN states that this is the best place to deal with TLS Resources.
Keep in mind that this callback is only calld for a thread exiting cleanly (not by e.g TerminateThread()).
Similar functionality is available with Fibers. From MSDN:
FlsAlloc, FlsCallback, FlsFree
FlsCallback Callback Function
An application-defined function. If
the FLS slot is in use, FlsCallback is
called on fiber deletion, thread exit,
and when an FLS index is freed.
You can simply call WaitForSingleObject on the thread handle.
You could try installing an IAT patching API hook on ExitThread()...
The advantage of this is that you'd get to run in the context of the thread that is exiting which may or may not be useful to you.
See this posting: Windows API spying/hijacking techniques for some details on this kind of hooking...
This question already has answers here:
Analyzing Multithreaded Programs [closed]
(7 answers)
Closed 9 years ago.
I have an application written in C++ and MFC which is multithreaded running on windows. Occasionally I do get some complaints such as deadlocks or an unhandled exception which is caused because of these threads. Normally I use visual studio (if the problem is reproducible) or else use the WinDbg to analyse the dump files generated. Is there any better way of doing this? Can I use some other tools to do this?
I would recommend the Intel Thread Checker if you have enough budget for it. It does a great job of analysing running programs and alerting you to possible race conditions.
Check out the demonstration video for more info.
I haven't gotten to use it yet, but the Relacy Race Detector sounds pretty useful for tracking down some classes of threading issues.
If you're deadlocking on CRITICAL_SECTIONs, you can use the !locks debugger extension in WinDbg to find out which thread owns a held lock, then use the kb command to look at that thread's callstack.
Multithreaded system are complex and location of blockages is not made only with appropriate tools. To find the cause of the deadlock you can put a record of the lock / unlock in a table map. When starting an "action lock" you save in the table, when unlock ocours delete the record from the table. At the end of a cycle you can log the state of the table or expect a particular event to do this.
Build this implementation in a dll, so you can use it in other projects too.
I have been a C programmer for many years and my favorite "debugger" has always been the printf() function - I only resort to visual studio's debugger when absolutely forced and so have never been very proficient in using it. Recently I have had to modify a program from C to C++ (although of course printf still works fine) and and parts of the program are now farmed out in to multiple threads (one for each core on a multicore machine) to make the program run faster. Now i will no doubt come up against awkward multi-thread related bugs like deadlocks and I wonder what debugging methodology I can turn to. Does visual studio (2008) have everything I could reasonably need to help me resolve thread related bugs? Should I take some time out now to learn how to use some third party debugger? Could I solve most problems using my good old printf?
Could I for example write code which, if kept waiting on entry to a critical section would print something like "Thread X waiting to enter ... but blocked because its being used by thread Y"?
Visual Studio supports thread debugging to some extend. Via the Threads Window you can select threads, suspend and resume threads etc. When you switch between threads the Call Stack Window is updated accordingly so you can inspect what each thread is doing. You may also restrict breakpoints to specific threads.
If you want an alternative WinDbg (which is part of the free Debugging Tools for Windows package from Microsoft) offers lots of options as well but with a slightly more esoteric user interface.
As for using printf, there's the problem of synchronizing output. If you don't do it you output will most likely be gibberish. If you do synchronize it you basically change the concurrency of the application, which may or may not affect the problem you're trying to solve.
If you could port your project to Linux, Valgrind (especially the 'helgrind' tool) would do exactly what you ask. http://valgrind.org/
I'm not sure if this is exactly what you are asking, but, To help in debugging, you can write code that gives each thread a "name", so that debug messages printed to the debug window, (or a log file or whatever) include that thread "name" along with whatever other info you prescribe. The code below is in C# but this is available even in unmanaged C++
Thread T = new Thread(RunSchedule);
T.Name = "Scheduler"; // <=== Thread given a name here...
T.Start();
Intel provides several tools to find out threading-related issues: data races, deadlocks, performance penalties. These tools are: Intel Thread Checker, Intel Thread Profiler.