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()
Related
This might well be a duplicate, but I haven't found a Q&A or example quite down to my level...
I'm trying to add interrupt handling to a simple Linux driver (which currently just implements mmap for some hardware registers). I want to keep as much functionality as possible in user-space for now, for flexibility of development. So I just want the kernel driver to handle (and clear) the IRQ, and implement either a poll or read file operation so user code can wait for it efficiently.
I don't plan to poll or read from more than one thread, so I don't care if it's single-wakeup or broadcast. I do care about cases where an interrupt happens before poll starts: this should cause the next poll (or read) to return immediately.
My question is about the synchronization between the ISR and the file operation. What kind of synchronization object(s) or pattern is appropriate? The examples I've seen mostly involve a "wait queue", which might produce a race condition if the interrupt occurs just after checking for it but before the poll gets onto the queue.
(Coming from an RTOS background, what I feel I want is a binary semaphore that the ISR can raise, and the poll (or read) operation can pend. I'm not sure if that's available in Linux?)
Thanks
For completeness, having pored through LDD3, I'll sketch an answer to my own question.
The quick answer: UIO
As Ian Abbott suggested above. It's for just this kind of scenario.
The long answer: Wait Queue does the right thing
I'd misunderstood the function of poll_wait() which doesn't actually wait, but merely registers the poll with the queue in some magical way. It is safe (and normal) to call it with a lock held. So there is no race condition.
A well-behaved driver would implement both poll and read.
Aside: LDD3 is very old. It pre-dates Platform and DevRes and probably many other things a driver writer should know about. Is there a modern equivalent (not necessarily free)?
This is a bit of a meta question since I think I have a solution that works for me, but it has its own downsides and upsides. I need to do a fairly common thing, catch SIGSEGV on a thread (no dedicated crash handling thread), dump some debug information and exit.
The catch here is the fact that upon crash, my application runs llvm-symbolizer which takes a while (relatively speaking) and causes a yield (either because of clone + execve or exceeding the time quanta for the thread, I've seen latter happen when doing symbolication myself in-process using libLLVM). The reason for doing all this is to get a stack trace with demangled symbols and with line/file information (stored in a separate DWP file). For obvious reasons I do not want a yield happening across my SIGSEGV handler since I intend to terminate the application (thread group) after it has executed and never return from the signal handler.
I'm not that familiar with Linux signal handling and with glibc's wrappers doing magic around them, though, I know the basic gotchas but there isn't much information on the specifics of handling signals like whether synchronous signal handlers get any kind of special priority in terms of scheduling.
Brainstorming, I had a few ideas and downsides to them:
pthread_kill(<every other thread>, SIGSTOP) - Cumbersome with more threads, interacts with signal handlers which seems like it could have unintended side effects. Also requires intercepting thread creation from other libraries to keep track of the thread list and an increasing chance of pre-emption with every system call. Possibly even change their contexts once they're stopped to point to a syscall exit stub or flat out use SIGKILL.
Global flag to serve as cancellation points for all thread (kinda like pthread_cancel/pthread_testcancel). Safer but requires a lot of maintenance and across a large codebase it can be hellish, in addition to a a mild performance overhead. Global flag could also cause the error to cascade since the program is already in an unpredictable state so letting any other thread run there is already not great.
"Abusing" the scheduler which is my current pick, with my implementation as one of the answers. Switching to FIFO scheduling policy and raising priority therefore becoming the only runnable thread in that group.
Core dumps not an option since the goal here was to avoid them in the first place. I would prefer not requiring a helper program aside from from the symbolizer as well.
Environment is a typical glibc based Linux (4.4) distribution with NPTL.
I know that crash handlers are fairly common now so I believe none of the ways I picked are that great, especially considering I've never seen the scheduler "hack" ever get used that way. So with that, does anyone have a better alternative that is cleaner and less riskier than the scheduler "hack" and am I missing any important points in my general ideas about signals?
Edit: It seems that I haven't really considered MP in this equation (as per comments) and the fact that other threads are still runnable in an MP situation and can happily continue running alongside the FIFO thread on a different processor. I can however change the affinity of the process to only execute on the same core as the crashing thread, which basically will effectively freeze all other threads at schedule boundaries. However, that still leaves the "FIFO thread yielding due to blocking IO" scenario open.
It seems like the FIFO + SIGSTOP option is the best one, though I do wonder if there are any other tricks that can make a thread unschedulable short of using SIGSTOP. From the docuemntation it seems like it's not possible to set a thread's CPU affinity to zero (leaving it in a limbo state where it's technically runnable except no processors are available for it to run on).
upon crash, my application runs llvm-symbolizer
That is likely to cause deadlocks. I can't find any statement about llvm-symbolizer being async-signal safe. It's likely to call malloc, and if so will surely deadlock if the crash also happens inside malloc (e.g. due to heap corruption elsewhere).
Switching to FIFO scheduling policy and raising priority therefore becoming the only runnable thread in that group.
I believe you are mistaken: a SCHED_FIFO thread will run so long as it is runnable (i.e. does not issue any blocking system calls). If the thread does issue such a call (which it has to: to e.g. open the separate .dwp file), it will block and other threads will become runnable.
TL;DR: there is no easy way to achieve what you want, and it seems unnecessary anyway: what do you care that other threads continue running while the crashing thread finishes its business?
This is the best solution I could come up (parts omitted for brevity but it shows the principle) with, my basic assumption being that in this situation the process runs as root. This approach can lead to resource starvation in case things go really bad and requires privileges (if I understand the man(7) sched page correctly) I run the part of the signal handler that causes preemptions under the OSSplHigh guard and exit the scope as soon as I can. This is not strictly C++ related since the same could be done in C or any other native language.
void spl_get(spl_t& O)
{
os_assert(syscall(__NR_sched_getattr,
0, &O, sizeof(spl_t), 0) == 0);
}
void spl_set(spl_t& N)
{
os_assert(syscall(__NR_sched_setattr,
0, &N, 0) == 0);
}
void splx(uint32_t PRI, spl_t& O) {
spl_t PL = {0};
PL.size = sizeof(PL);
PL.sched_policy = SCHED_FIFO;
PL.sched_priority = PRI;
spl_set(PL, O);
}
class OSSplHigh {
os::spl_t OldPrioLevel;
public:
OSSplHigh() {
os::splx(2, OldPrioLevel);
}
~OSSplHigh() {
os::spl_set(OldPrioLevel);
}
};
The handler itself is quite trivial using sigaltstack and sigaction though I do not block SIGSEGV on any thread. Also oddly enough syscalls sched_setattr and sched_getattr or the struct definition weren't exposed through glibc contrary to the documentation.
Late Edit: The best solution involved sending SIGSTOP to all threads (by intercepting pthread_create via linker's --wrap option) to keep a ledger of all running threads, thank you to suggestion in the comments.
We have a Linux embedded project and we are concerned with performance.
The Serial port Asynchronous Input example at:
http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html#AEN105
pretty much does what we want.
However the engineer in charge objects to the CPU performance lost by the
looped sleep call. He would like the program to wait for a signal to execute the response handling code instead.
I tried moving that code from main() to inside the signal function, i.e.:
void signal_handler_IO (int status)
{
// I moved my code here
}
The result does not work, writes to the serial port made in that function quickly fail and the program becomes completely unresponsive.
Why is that?
And does anyone have a good online example of Signal-Driven I/O for just one serial port? I have been poring over Chapter 63 of Kerrisk's "The Linux Priogramming Interface" book and googling like crazy. I am beginning to think there might not be a better way to do the initial example.
Thanks in advance,
Bert
If you are worried about waking up regularly from the usleep() call when there is no input available, simply replace the usleep() call with a pause(), that will suspend your process until the SIGIO occurs.
In general, doing anything complicated (i.e., touches things beyond the immediate stack) in a signal handler is dangerous -- see http://www.gnu.org/s/libc/manual/html_node/Nonreentrancy.html for a fairly thorough description. I/O operations are particularly unsafe, as they tend to do allocations and poking of hardware and such.
If you don't like the explicit wait loop, you might try using semaphores -- see
http://linux.die.net/man/7/sem_overview for details. In particular, sem_post is explicitly documented as safe for use in signal handlers, so you can put a (blocking) call to sem_wait in your read loop in place of the usleep, and then unblock it by calling sem_post in your signal handler.
Please point me the tools or the way to monitor which thead in running in the millisecond level? Thanks.
Suppose I have 3 thread running , and I want infomation like below:
0 - 20ms thread1
20 - 40ms thread2
40 - 50ms thread1
50 - 70ms thread3
NOTES: I perfer to solve this problem without hacking into kernel.
EDIT :
in MIPS platfrom with 2.6.21 Linux Kernel
command TOP can provide some information about thread but not too much.
You can use LTTng to trace scheduling activity (along with lots of other things!) with a suitably configured kernel.
That said, I looked at your nabble link - your real problem seems to be that your write thread is blocking the read thread, right? One thing to consider trying would be to use a database that supports concurrent reads and writes. Or use a locking protocol to block the write thread when the read thread is active.
For example, you could have a mutex, condvar, and a want_read value. Before each write, the write thread takes the mutex and checks the wants_read value. If it's nonzero, it blocks on the condvar. Meanwhile, the read thread will increment wants_read under the mutex when it begins, and, when done, decrements it and broadcasts on the condvar. This should cause the write thread to block as soon as is safe when the read thread wants in.
For your specific problem you mentioned in comment, thread without usleep will make a thread busy which will take much of the processor resource. Then you will get a slow database search response.
For general thing if you want check the thread schedule sequence, and do not want to bother install lttng, you can a trick I used. I add some simple syscall like open, close, time with invalid parameter to the thread's key path (which is low overhead compare to printf, and printf sometimes involved with thread lock), and then you can use strace tool to track all these threads. Check the strace log, you can see when they are scheduled in when other thread are sheduled in. Then you will get a general idea what the thread take most of the time to do, and which thread take most of the system's time.
Lttng is definitely the best tool for such problem only if you can get it work.
Intel Concurrency Checker will work on windows and linux. I haven't used it, so I don't know a lot of details, but I have heard that it will do performance measurements. It might be worth a try.
Take a look at the Performance Inspector tools.
I'm developing a DirectShow application. I encounter a deadlock problem, the problem seems caused by acquire lock in a callback function called from a thread. This is the quest I asked in MSDN forum:
http://social.msdn.microsoft.com/Forums/en-US/windowsdirectshowdevelopment/thread/f9430f17-6274-45fc-abd1-11ef14ef4c6a
Now I have to avoid to acquire lock in that thread. But the problem is, I have to output the audio to another thread, how can I put data to another thread without lock?
There's someone tell me that I can use PostMessage of win32 sdk to post data to another thread. But however, to get the message, I have to run a windows program. My program is a Python C++ extension module. That might be very difficult to add a loop to pull message. So I am think another way to pass data among threads without locking.
(Actually... the producer thread can't be locked, but the consumer thread can do that. )
To lock or not to lock, that's the question.
So the question is how to do?
Thanks.
------EDIT------
I think I know why I got a deadlock, that might not be the problem of DirectShow.
The main thread is own by Python, it call stop, namely, it hold GIL. And the stop wait for callback of DirectShow in thread return. But callback acquire the GIL.
It looks like this
Main(Hold GIL) -> Stop(Wait callback) -> Callback(Wait GIL) -> GIL(Hold by Main thread)
Damn it! That's why I don't like multi-thread so much.
No matter what, thanks your help.
If you were doing this in pure Python, I'd use a Queue object; these buffer up data which is written but block on read until something is available, and do any necessary locking under the hood.
This is an extremely common datatype, and some equivalent should always be available, whatever your current language or toolchain; there's a STL Queue available in C++, for instance, but the standard doesn't specify thread-safety characteristics (so see your local implementation docs).
Well, theoretically locks can be avoided if both of your threads can work on duplicate copies of the same data. After reading your question in the MSDN forum...
"So to avoid deadlock, I should not acquire any lock in the graber callback function? How can I do if I want to output audio to another thread?"
I think that you should be able to deposit your audio data in a dequeue (an STL class) and then fetch this data from another thread. This other thread can then process your audio data.
I am glad that your problem has been resolved the reason I asked about your Os was that the documentation you referred to said that you should not wait on other threads because of some problem with win16Mutexes. There are no win16mutexes on windows XP (except when programs are running on ntvdm/wow16) so you should be able to use locks to synchronize these threads.