I want to yield a multithreaded process in Linux. I know a thread can be yielded by calling sched_yield. I guess, on the other hand, the whole process can be yielded by calling sleep(0), since sleep works at process level. Am I right?
sched_yield will yield the thread that is currently running, relinquishing the rest of its timeslice. The processor then context switches to the next thread. Whether that thread is another which belongs to your process is unknown. It could be, it might not be.
To yield the whole process you would therefore need to yield each thread that existed in that process. sleep works similarly. It will sleep for that particular thread, not the whole process.
Wrong.
sleep(3)
sleep() makes the calling thread sleep until seconds seconds have
elapsed or a signal arrives which is not ignored.
EDIT
From the comments I see people use an outdated site for the manual pages. Stop using that site, use the kernel.org pages which should be up-to-date.
Related
For a simple sampling profiler I'm suspending a target thread, get its current stacktrace, then continue it.
Now I would like to highlight a sample differently if the thread was in a waiting state.
So I want to know if the thread was blocking (waiting via WaitForSingleObject, pausing via Sleep, ...) at the time it was suspended.
I can get this information via NtQuerySystemInformation(SystemProcessInformation), but that gets much more than needed, the information of each thread of each process.
Also I saw Performance Counters, but I'm not sure if it's possible with this API, if I only have the thread ID/handle.
UPDATE:
IInspectable gave me a hint with Wait Chain Traversal, while it seemed a good fit, it gives back the status ObjectStatus==WctStatusBlocked for all suspended threads, which isn't unreasonable, but doesn't work for my problem. It is also very slow, I assume because it collects the data for the whole chain, while I only care for the first element.
While not exactly what I wanted, QueryThreadCycleTime is close enough.
So each time the thread is suspended, QueryThreadCycleTime is called, which returns the number of CPU clock cycles used by this thread up to this point.
If the difference to the previous call is below a certain limit, the current sample is then considered as waiting.
It's not perfect, the first sample taken while the thread entered a waiting state is not detected as waiting, and the limit might not work for all CPUs the same.
If I have a process whose all threads are running on different cores, what will sched_yield do in that case? Get relinquished and immediately issued again? Because what I see is that sched_yield does not cause the thread calling it, wait any cycles at all, it seems that the call is not even going to the kernel.
As far as the linux kernel is concern, one core is one CPU, so sched_yield would causes the calling thread to relinquish the CPU but if the thread is the only one in the queue, it won't wait any cycle.
So yes in your case sched_yield would immediatly return immediatly if there are no thread waiting on the current core.
Note that sched_yield is not designed to control how threads are run on multiple CPU.
The man page says:
If the calling thread is the only thread in the highest priority
list at that time, it will continue to run after a call to sched_yield().
So if there's nothing more important to run, the function will basically do nothing.
"The wait() system call suspends execution of the current process until one of its children terminates" . Waitpid also is similar.
My Question is whether calling wait() from one thread will cause all other threads (in the same process) also to go to sleep ? Do the behavior is same for detached threads also?
This is just a bug in the manual. wait suspends the calling thread, not the process. There is absolutely no way to suspend the whole process short of sending it SIGSTOP or manually suspending each thread one at a time.
As far as I know, calling wait from any thread will cause all threads which are associated with that process to halt.
But don't hold me to that. Best thing to do would be to test it.
Should only stop the current thread. If you want to make people ill when they look at your code and cause yourself a lot of problems you can use this for jury rigged thread synchronization. I wouldn't reccommend it though.
Looks like linux doesnt implement pthread_suspend and continue, but I really need em.
I have tried cond_wait, but it is too slow. The work being threaded mostly executes in 50us but occasionally executes upwards of 500ms. The problem with cond_wait is two-fold. The mutex locking is taking comparable times to the micro second executions and I don't need locking. Second, I have many worker threads and I don't really want to make N condition variables when they need to be woken up.
I know exactly which thread is waiting for which work and could just pthread_continue that thread. A thread knows when there is no more work and can easily pthread_suspend itself. This would use no locking, avoid the stampede, and be faster. Problem is....no pthread_suspend or _continue.
Any ideas?
Make the thread wait for a specific signal.
Use pthread_sigmask and sigwait.
Have the threads block on a pipe read. Then dispatch the data through the pipe. The threads will awaken as a result of the arrival of the data they need to process. If the data is very large, just send a pointer through the pipe.
If specific data needs to go to specific threads you need one pipe per thread. If any thread can process any data, then all threads can block on the same pipe and they will awaken round robin.
It seems to me that such a solution (that is, using "pthread_suspend" and "pthread_continue") is inevitably racy.
An arbitrary amount of time can elapse between the worker thread finishing work and deciding to suspend itself, and the suspend actually happening. If the main thread decides during that time that that worker thread should be working again, the "continue" will have no effect and the worker thread will suspend itself regardless.
(Note that this doesn't apply to methods of suspending that allow the "continue" to be queued, like the sigwait() and read() methods mentioned in other answers).
May be try an option of pthread_cancel but be careful if any locks to be released,Read the man page to identify cancel state
Why do you care which thread does the work? It sounds like you designed yourself into a corner and now you need a trick to get yourself out of it. If you let whatever thread happened to already be running do the work, you wouldn't need this trick, and you would need fewer context switches as well.
I spent a good long while looking for info on the differences between time.h::sleep() and pthread.h::pthread_yield() but was unable to find any solid reference material and so I am posting this question.
What is the difference between time.h::sleep() and pthread.h::pthread_yield()?
Update:
The reason I ask is because I was using sleep() to sleep() each individual thread... and my application started having issues when there was 8 threads vs 4 threads. When I went online to see if sleep() only affects each thread, I couldn't find any good reference stating whether Sleep() affects the entire process OR sleep() only affects the individual thread.
From pthread_yield:
The pthread_yield subroutine forces the calling thread to relinquish use of its processor, and to wait in the run queue before it is scheduled again. If the run queue is empty when the pthread_yield subroutine is called, the calling thread is immediately rescheduled.
From the sleep manpage:
sleep() makes the calling process sleep until seconds seconds have elapsed or a signal arrives which is not ignored.
If you don't want to have a real time delay in your threads and just want to allow other threads to do their work, then pthread_yield is better suited than sleep.
sleep() causes your program to stop executing for a certain length of time. No matter what else happens on the system, your thread will not start again until at least the length of time passed to sleep() has elapsed. pthread_yield() notifies the operating system that your thread is done working, and that it can switch execution to another thread. However, if there is no higher-priority thread that needs to do work at that time, your thread may start again immediately.
IOWs, after sleep() your thread is guaranteed to stop running even if no one else needs to run, while pthread_yield() is just a polite way to give other threads a chance to run if they need to.
Update in response to question update: both sleep() and pthread_yield() affect only the calling thread.
sleep(s) takes the current thread of execution and suspends it until s seconds have passed (or it is woken up by a signal.)
In more practical terms, when you call sleep(), that thread will cease execution and just... wait until the specified time has passed. Once it passes, that thread is placed into the ready queue.
pthread_yield() says "take this thread, and put it into the ready queue." Your thread will stop execution and be in the 'waiting' state to be selected/run by the scheduler. This does not gaurantee that your thread will not immediately resume running. But it gives another thread a chance to run at a given point in its execution.
I am going to go out on a limb and say that sleep(0) would accomplish the same thing as a pthread_yield() - both stopping execution and placing the thread in the ready queue.