I need to detect whether a given thread is currently scheduled to a CPU or not. I am on a linux system with pthreads. Say that my code is running on a signal handler and I know that there are threads X and Y in my app, and from within my signal handler I want to check if X and Y are currently scheduled or not.
Thanks for your help.
In general if you have to ask this question, you are probably thinking incorrectly. Whatever answer you are going to get is going to be immediately outdated and whatever you plan to do about the answer is going to be subject to massive race conditions.
However, in theory you can look at /proc/getpid()/task/threadid/status and find out if a particular thread is running or not. Note this is very much a linux thing and any mapping between "threadid" and pthread_self()'s return code or pthread_create's pthread_t copy-out is very much not a standard.
Related
what is the difference between thread and process, i know you think this is duplicate , but seriously no where and nobody given one exact and to the point answer . I am really tired when somebody says thread are light weight process , even books does not clearly mention it why ?
So I gone through different stackoverflow answer and made a final answer. I feel it is incomplete. Please contribute to this answer ,as it will really help thousand of people who still struggling to understand this puzzle.
My research reached till here so far ....
Linux calls clone API for creation of thread and creation of process , only difference is there are 28 flags which are configured differently for thread and process.
https://stackoverflow.com/a/64942352
I'm not qualified to speak about the implementation of Linux threads. (I've heard that it has been evolving over the past decade or so.) But, the purpose of threads and processes has remained pretty stable:
A thread is an execution path through your program's code. That's pretty much all there is to say about that.
A process is a container for all of the resources needed by an instance of your program; The process has a virtual address space, it has open file handles, it may have sockets, it may have memory mappings, it may own IPC objects, I'm not sure what all else. And, a process has some number of threads. (Always at least one thread, sometimes more.)
The threads in your program do all the work. The process is the place in which they do the work.
I have a real-time thread in Linux (3.4). Under certain conditions, I want it to relinquish control to other threads with the same priority, even if it hasn't finished using up its current timeslice. I was thinking of using the following code:
if (condition) {
resched_task();
cond_resched();
}
however, I don't see anyone else in the code doing this, making me think there's some other (better?) way of doing this. Is there a standard way to do this?
You can use the sched_yield() function to yield the rest of your time slice, as discussed here.
sched_yield() causes the calling thread to relinquish the CPU. The thread is moved to the end of the queue for its static priority and a new thread gets to run.
The question sounds like it's asking about kernel programming but the accepted answer is a function user mode API sched_yield(). I think the kernel answer to this question is schedule()
Suppose I need to peek on a thread's state at regular intervals and record its state along the whole execution of a program. I wouldn't know how to start thinking about this. Any pointers (pun?)? I'm on Linux, using gcc, phreads and C and have access to all usual Linux tools. Basically, I guess I'm asking about how to build a simple profiler for threads that will tell me how long a thread has been in some or other state during the execution of the program.
I want to be able to create graphs like Threadscope does. The X axis is time, the Y axis is core/thread number and the "colors" are state: green means running, orange is garbage collection, and so on. Does this make more sense now?
.
For Linux specific solution, you might like to have a look at /proc/<pid>/stat and /proc/<pid>/task/<tid>/stat for process and thread statistics, respectively. Have a look at proc(5) manual page for full description of all the fields there (online http://man7.org/linux/man-pages/man5/proc.5.html - search for /proc/[pid]/stat). Specifically, at least the fields cutime and stime are of interests to you. These are monotonically increasing times, so you need to remember the previously measured value to be able to produce the time spent in the process/thread during the given time slice, in order to produce the data for your graphs. (This is how top(1) works.)
However, for the profiler to distinguish different states makes the problem more complicated. How do the profiler distinguish that the profiled program is in which state? It seems to me the profiled program threads need to signal this in some way to the profiler. You need to have some kind of tailored solution for this state sharing (unless you can run the different states in different threads and make the distinction this way, which I doubt).
If the state transitions are done in single place (e.g. enter GC and leave GC in your example), then one way would be as follows:
The monitored threads would get the start and end times of the special states by using POSIX function clock_gettime() - with clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp) you can get the process time and with clock_gettime(CLOCK_THREAD_CPUTIME_ID, &tp) you can get the thread time (both monotonically increasing, again).
The thread could communicate these timings to the profiler program with some kind of IPC.
If the profiler application knows the thread times of entering and leaving a state, then because it knows the thread time values at the change of measuring slices, it can determine how much of the thread time is spent in the reported states within a reporting time slice (and of course here we need to adjust the start time for a state to equal the start of the next reporting time slice).
The time the whole process has spent on a specific state can be calculated by summing up the thread times for that state.
Note that through /proc/<pid>/stat or /proc/<pid>/task/<tid>/stat, the measurement accuracy is not very good (clock ticks, often units of 10ms), but I do not know other way of getting timing information from outside of the process/thread. The function clock_gettime() gives very accurate times (nominally nanosecond accuracy, but note that at least in some MIPS and ARM systems the accuracy is as bad as with the stat files under /proc due to unexisting implementation of accurate timer reading for these fields within Linux kernel). You also would need to do some experimentation to make sure these two timing sources really would give the same results (by reading both values from the same threads). You can of course use these /proc/.../stat files inside the thread, but the accuracy just is not very good unless you spend a lot of time within a state.
Well, the direct match to profiling info produced by the haskell compiler and processed by Threadscope is, using C and GCC, the gprof utility (it's part of the GNU binutils).
For it to work correctly with pthreads you need each thread to trigger some timer initialization function. This can be done without modifying your code with this pthreads wrapper library: http://sam.zoy.org/writings/programming/gprof.html . I haven't dealt with the problem recently, it may be that something has changed and the wrapper isn't needed anymore...
As to GUI to interpret the profiling results, there is kprof (http://kprof.sourceforge.net). Unfortunately, AFAIK it doesn't produce thread duration graphs, for that you'll have to work your own solution with the textual info produced by gprof.
If you are not picky about using the "standard" solution offered by the GCC, you may wanna try this: http://code.google.com/p/gperftools/?redir=1 (didn't try it personally, but heard good opinions).
Good luck!
Take a look at at Intel VTune Amplifier XE (formerly … Intel Thread Profiler) to see if it will meet your needs.
This and other Intel Linux development tools are available free for non-commercial use.
In the video Using the Timeline in Intel VTune Amplifier XE showing a timeline of a multi-threaded application, at 9:20 the presenter mentions
"...with the frame API you can programmatically mark certain events or phases in your code. And these marks will appear on the timeline."
I think it will be rather difficult build a simple profiler simply because there are many different factors that you have to consider and system profiling is an inherently complex task, made all the more so when you are profiling a multithreaded application. The best advice I can think of is to look at something that already exists, for example OProfile.
One advantage of OProfile is that it is open source so the source code is available. But beyond this I suspect that asking how to build a profiling application might be beyond the scope of what someone can answer in a SO question, which might be why this question hasn't gotten very many responses. Hopefully looking at some example will help you get started and then perhaps if you have more focused questions you could get some more detailed responses.
I am working on a big project that uses RTAI both in kernel and user spaces. I won't get into the details of the project, but here is briefly where a problem arises.
In user-space, my project provides a library used by other people to write some software. Those programs themselves may have RTAI real-time threads.
Now, some functions in RTAI require that their calling thread have already rt_thread_inited so if I want to use them in a function in the library, I need to temporarily make the calling thread real-time by calling rt_thread_init and later rt_task_delete.
Now here's the problem:
If the calling thread of my function IS already real-time, then I am rt_thread_initing which I assume simply fails, but then I rt_task_delete and make that thread non-real-time (besides the fact that when the thread itself (assuming I changed nothing) again rt_task_deletes, RTAI crashes.
If the calling thread of my function IS not real-time, everything is ok.
For now, I resorted to taking a parameter in the function so that the calling function tells the library if it is real-time or not. However, I wanted to know if RTAI has a function or something so I could use to automatically detect whether the current thread is real-time or not.
Don't know if there are any RTAI users here (I certainly didn't see the RTAI tag), but hope there would be.
Never tried it myself, so this is a guess - but did you consider using rt_whoami?
Get the task pointer of the current task.
https://www.rtai.org/documentation/magma/html/api/api_8c.html#a12
I would imagine it will fail (return NULL?) if you are in a non RT task...
Not really programming related this question, but I still hope it fits somehow here :).
I wrote the following sentence in my work:
Mulitthreading refers to the ability of an OS to subdivide an application into
threads, where each of the them are capable to execute independently.
I was told, that this definition of thread is too narrow. I am not really sure why this is the case, could somebody be so kind to explain me what I missed?
Thank you
Usually, it is the application that decides when to create threads, not the OS. Also, you may want to mention that threads share address space, while each process has its own.
A thread fundamentally, is a saved execution context - a set of saved registers and a stack, that you can resume and continue execution of. This thread can be executed on a processor (these days, many machines of course can execute multiple threads at the same time).
The critical aspect of "multi-threading" is, that an operating system can emulate execution of many threads at the same time, by preempting (stopping) a thread once it has run for a certain amount of time (a "quantum"), then scheduling another thread to run, based on a certain algorithm that is OS-specific.