This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Bind threads to processors
In Linux, is it possible to fix threads to execute on certain cores. If that is possible, I also want to know if it is possible to execute one thread exclusively on a certain core, that is disallowing any other thread to execute on that core while that thread is executing.
That's what pthread_setaffinity_np(3) does.
The pthread_setaffinity_np() function sets the CPU affinity mask of
the thread thread to the CPU set pointed to by cpuset. If the call is
successful, and the thread is not currently running on one of the CPUs
in cpuset, then it is migrated to one of those CPUs.
As an example:
cpu_set_t set;
CPU_ZERO(&set);
CPU_SET(3, &set); /* Run only on the third CPU. */
pthread_setaffinity_np(thr, CPU_SETSIZE, &set);
You can also do it with sched_setaffinity(2) and gettid, but that manual page says:
If you are using the POSIX threads API, then use
pthread_setaffinity_np(3) instead of sched_setaffinity().
Related
This question already has answers here:
How does sleep(), wait() and pause() work?
(4 answers)
Closed 2 years ago.
In C, how does the sleep function work? At the background is a while loop created? Or for loop? I would like to know exactly what lib does, how could I recreate a sleep in a simple way without having to use lib?
It's not implemented with a loop of any kind (that would waste energy occupying a core when you're doing nothing); it's a system call in which you tell the OS to suspend the current thread and wake it after the interval has elapsed (the exact mechanism used varies by OS). Reimplementing it yourself is ultimately going to depend on a system call and/or signals in some way; don't bother, just use sleep (or nanosleep, or Sleep, depending on OS).
This question already has answers here:
How to detect the launching of programs on Linux?
(8 answers)
Closed 7 years ago.
I am writing a C program that runs in the background of the Linux shell and if the total memory consumption is over 85% of the total memory, then it will print out a warning. What would be the best way to check if a new process was created (I want to check the values for the memory every time a process is created)?
The most effective way of determining when processes are created (and exit) will be to use the proc connector. It's somewhat complex to use, but will notify your process immediately when events occur.
However, keep in mind that the memory usage of processes can change dramatically while they are running. Monitoring for processes being created is almost certainly not going to be sufficient for your needs; you will need to poll memory usage periodically. (There is no general way to get notifications for system memory usage, short of running your processes in a cgroup with a memory controller and registering an OOM handler. You don't want to do this.)
I have a project with some soft real-time requirements. I have two processes (programs that I've written) that do some data acquisition. In either case, I need to continuously read in data that's coming in and process it.
The first program is heavily threaded, and the second one uses a library which should be threaded, but I have no clue what's going on under the hood. Each program is executed by the user and (by default) I see each with a priority of 20 and a nice value of 0. Each program uses roughly 30% of the CPU.
As it stands, both processes have to contended with a few background processes, and I want to give my two programs the best shot at the CPU as possible. My main issue is that I have a device that I talk to that has a 64 byte hardware buffer, and if I don't read from it in time, I get an overflow. I have noted this condition occurring once every 2-3 hours of run time.
Based on my research (http://oreilly.com/catalog/linuxkernel/chapter/ch10.html) there appear to be three ways of playing around with the priority:
Set the nice value to a lower number, and therefore give each process more priority. I can do this without any modification to my code (or use the system call) using the nice command.
Use sched_setscheduler() for the entire process to a particular scheduling policy.
Use pthread_setschedparam() to individually set each pthread.
I have run into the following roadblocks:
Say I go with choice 3, how do I prevent lower priority threads from being starved? Is there also a way to ensure that shared locks cause lower priority threads to be promoted to a higher priority? Say I have a thread that's real-time, SCHED_RR and it shared a lock with a default, SCHED_OTHER thread. When the SCHED_OTHER thread gets the lock, I want it to execute # higher priority to free the lock. How do I ensure this?
If a thread of SCHED_RR creates another thread, is the new thread automatically SCHED_RR, or do I need to specify this? What if I have a process that I have set to SCHED_RR, do all its threads automatically follow this policy? What if a process of SCHED_RR spawns a child process, is it too automatically SCHED_RR?
Does any of this matter given that the code only uses up 60% of the CPU? Or are there still issues with the CPU being shared with background processes that I should be concerned with and could be caused my buffer overflows?
Sorry for the long winded question, but I felt it needed some background info. Thanks in advance for the help.
(1) pthread_mutex_setprioceiling
(2) A newly created thread inherits the schedule and priority of its creating thread unless it's thread attributes (e.g. pthread_attr_setschedparam / pthread_attr_setschedpolicy) are directed to do otherwise when you call pthread_create.
(3) Since you don't know what causes it now it is in fairness hard for anyone say with assurance.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm looking for an open source timer library written in C. The library should have Timer callback functions, etc.
On searching I see POSIX timers or setitimer(), which use a signal based approach that may lead to problems in multithreaded code.
Say if I use POSIX Timers inside threaded code, the signals won't be reaching to the correct place. If I use several timers in a process then each one should use different signals. Are there any other alternatives?
Since you are running Linux, I would recommend using the built in POSIX timer API's.
int timer_create(clockid_t clockid, struct sigevent *sevp, timer_t *timerid);
Here is a link to some documentation showing how to use POSIX timers which provide support for callback functions.
Regarding multiple timers in a process, the documentation says this:
A program may create multiple interval timers using timer_create().
Timers are not inherited by the child of a fork(2), and are disarmed and
deleted during an execve(2).
The kernel preallocates a "queued real-time signal" for each timer created
using timer_create(). Consequently, the number of timers is limited by the
RLIMIT_SIGPENDING resource limit (see setrlimit(2)).
Note that POSIX timers can be used in a threaded application by setting up notification using SIGEV_THREAD_ID as shown below:
The sevp.sigev_notify field can have the following values:
SIGEV_NONE
Don't asynchronously notify when the timer expires. Progress of the
timer can be monitored using timer_gettime(2).
SIGEV_SIGNAL
Upon timer expiration, generate the signal sigev_signo for the process.
See sigevent(7) for general details. The si_code field of the
siginfo_t structure will be set to SI_TIMER. At any point in time, at
most one signal is queued to the process for a given timer; see
timer_getoverrun(2) for more details.
SIGEV_THREAD
Upon timer expiration, invoke sigev_notify_function as if it were the
start function of a new thread. See sigevent(7) for details.
SIGEV_THREAD_ID (Linux-specific)
As for SIGEV_SIGNAL, but the signal is targeted at the thread whose ID
is given in sigev_notify_thread_id, which must be a thread in the same
process as the caller. The sigev_notify_thread_id field specifies a
kernel thread ID, that is, the value returned by clone(2) or gettid(2).
This flag is only intended for use by threading libraries.
The Linux way of doing it would be via timerfd_create which integrates nicely with epoll-based event loops (and thereby avoiding the restrictions of signal handlers)
This is far to simple to create a library for.
example:
#include <time.h>
int main()
{
time_t start,end;
double dif;
double duration=40f; //duration of timer
bool loop=true;
while(loop==true)
{
time(&start);
if(dif==duration)
{
/*callback*/
dif=0;
}
//do stuff
time(&end);
dif+=difftime(end,start);
}
{
According to my question here I would like to use SCHED_RR with pthread_setschedparam for my threads in a Linux application. However, this has effects even on kernel modules which I currently cannot solve.
I have found http://www.icir.org/gregor/tools/pthread-scheduling.html which says that I could create my threads with PTHREAD_SCOPE_PROCESS attribute, but I haven't found further information on this.
Will this work with (Angstrom) Linux, kernel version2.6.32? (How) will this affect the way my process competes with other processes? Would it be the way to have my processes compete with real time scheduling but other processes would not be affected?
(As I am using boost threads I cannot simply try this...)
Threads created with PTHREAD_SCOPE_PROCESS will share the same kernel thread (
http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003674.html )
However, SCHED_RR must be run under a root-privileged process.
Round-Robin; threads whose contention scope is system
(PTHREAD_SCOPE_SYSTEM) are in real-time (RT) scheduling class if the
calling process has an effective user id of 0. These threads, if not
preempted by a higher priority thread, and if they do not yield or
block, will execute for a time period determined by the system.
SCHED_RR for threads that have a contention scope of process
(PTHREAD_SCOPE_PROCESS) or whose calling process does not have an
effective user id of 0 is based on the TS scheduling class.
However, basing on your linked problem I think you are facing a deeper issue. Have you tried setting your kernel to be more "preemptive"? Preemption should allow the kernel to forcibly schedule out of running your process allowing for more responsive running of some kernel parts. This shouldn't affect IRQs though, maybe something disabled your IRQs?
Another thing I am thinking about is maybe that you are not fetching your SPI data fast enough and the buffor for your data in the kernel becomes full and hence the data loss. Try increasing those buffers also.