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 4 years ago.
Improve this question
I've looked into the Linux kernel source and I was wondering what the kernel sees as a task? Because obviously the CPU runs machine instructions so I thought the scheduler fetches maybe the memory adress of the main function of a program and puts it on the CPU. Is that at least kind of correct? When I click on an executable program, what will actually happen inside the scheduler?
EDIT:
I saw several task-related structs in the source code that stored a bunch of integers and floats (flags, priority etc.)...But I am wondering how the scheduler finds the machine instructions of my programs.
At a minimum a task is a set of register values. One of them is the program counter. When the kernel switches task it stores the current values of all registers in the task structure for the old task. It then loads all the register values from the new task structure, loading the program counter last. This resumes the execution of that task.
Now the hard to understand part is that in most kernels the program counter isn't loaded at all at task switch. Now how can that switch tasks then?
The trick is that all task switching is always done in the same function, which must be written in ASM. So the program counter of the old task is always exactly the program counter of the new task. So it doesn't need to be loaded at all. Execution simply continues where it is. BUT the code now runs in the context of the new task. And when the function returns it returns from where previously the new task called the task switching function. Maybe it's simpler to understand if I say that the new tasks program counter is loaded from the stack when the task switch function returns.
Anyway, what the scheduler does is switch the whole CPU state from one task to the other. It's much more than just a function pointer in C. If you want a C equivalent then look at setjmp() + longjmp().
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
I need to write a C program that launches another program with a modified priority, much as as the nice command does. In order to do that, I would like to find the PID of a process given as an argument (how can I do that?) and modify its priority level (how can I do that?).
Example: The command line might be ./a.out 5 sleep 500 &, and this should produce the same effect as nice -n 5 sleep 500&.
You are focusing on the wrong thing and therefore approaching the problem with the wrong idea. The key requirement is that your program must execute a specified command. Focusing on that will lead you toward how to achieve the process priority goal, at least by helping you frame the question more usefully. For example, you don't need to find any PID, because you don't need to adjust the niceness of an arbitrary process.
So how do you programmatically launch another command? The typical way would be to use one of the functions from the exec family. Since the program name and arguments are comming from the command line, execvp() is probably your best choice.
If you read their docs, you will find that the exec functions replace the process image in the current process. That is, they make the process in which they are called start and run a different program in place of the one it was running before. If the command you're going to launch will run in the current process, then it's the current process whose niceness you want to adjust, and for that there is nice().
You shouldn't need much more than those two functions and a little command-line parsing. Do read those functions' documentation carefully, however, especially execvp()'s, to make sure you set up the arguments correctly.
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 5 years ago.
Improve this question
I have learned about the following problems that I can face when working with threads:
When you write a value to a variable in memory, the value is not necessarily written to the memory location (the value can be written to cache), and so if another thread is reading this variable, it will not read the value that the other thread just wrote.
Also, when you read from a variable in memory, the value is not necessarily read from the memory location (the value can be read from cache), and so if another thread wrote a value to this variable, and your thread is trying to read it, it will not read the value that the other thread just wrote.
You need to be careful that some tasks needs to be "atomic", so for example if two threads are doing calculations on a variable, you must not allow these two threads to do their calculations at the same time (one thread must wait for the other thread to finish its calculations).
The compiler and/or the CPU can execute your program instructions out of order.
You can have a deadlock (if each thread is waiting for the other thread to signal it before continuing).
Are there other problems that I can face when working with threads?
When you write a value to a variable in memory, the value is not necessarily written to the memory location (the value can be written to cache)
You're thinking about it at the wrong level of abstraction. What you say is true, but it's mostly of interest to the developers of the programming language toolchain that you use. From the perspective of an application developer, it's better to say that a value written to memory by one thread does not immediately become visible to other threads.
The compiler and/or the CPU can execute your program instructions out of order
Better to say that, when one thread writes several values to memory in sequence, other threads do not necessarily see the new values appear in the same sequence.
Within any single thread, the compiler and the CPU both must insure that everything appears to happen in program order.
...some tasks needs to be "atomic", so for example if two threads are doing calculations on a variable, you must not allow these two threads to do their calculations at the same time
True again, but that's not enough information to be useful. You need to know when and why two different threads can or can not do their calculations at the same time.
The key concept is invariants. An invariant is any condition that is always assumed to be true. E.g., if you are implementing a linked list structure, one invariant is that every "next" pointer either points to a member of the list or, to NULL. If you are implemeting a ring of linked nodes, then one invariant says that if you follow the chain of "next" pointers far enough, it will always take you back to where you started.
It's often the case that there is no way to perform some operation without temporarily breaking an invariant. E.g., you may be unable to insert something into some data structure without temporarily putting the structure into an invalid state.
You said, "some tasks needs to be 'atomic'". Better to say, some tasks require mutual exclusion (mutexes) to prevent one thread from seeing an invariant in a temporarily broken state caused by the action of some other thread.
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 6 years ago.
Improve this question
Using OpenMP I divided a simple algorithm in different threads but the execution time is increasing drastically. This may be due to all the threads running on same CPU core. I am aware that if my CPU is dual core or quad core then assigning number of threads more than number of CPU cores will not help much. but even with two threads the execution time is increasing.
Yes you can determine which CPU gets a thread.
By using for example the Thread Affinity Interface (Linux* and Windows*), as suggested by talonmies. However, notice what the article mentions though:
thread affinity can have a dramatic effect on the application speed.
For getting slower execution, two main reasons may apply:
1) If you have more threads than your cores, then the remaining threads will wait for the others, which reduces to serial execution.
With that said, assuming you have 2 cores, then having 4 threads ready for execution, will result in race conditions, since all these threads will compete for the resources (i.e. the cores), so 2 of them will execute in parallel, but the other two will have to wait.
2) Small size of your problem.
Running in parallel doesn't come for free. You have to do much housekeeping and in general orchestrate the parallel execution. You have to bring OpenMP into play and the OS has to handle more threads/processes as well.
So, unless the size of your problem is big enough, you won't see any speedup (even worse, you will see a slowdown as in your case), since the overhead of orchestrating the parallel execution will dominate the execution of your application.
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 6 years ago.
Improve this question
I want to be sure whether I should use <thread> in my code.
I am writting for a simple console game. It's like the letters I input fall down from the top of the console and I can remove them one by one by typing each letter in a real time. ( for the purpose of remembering names quickly. )
I think It should be split it into 2 parts, the one printing out the random letters which is falling down to the bottom( If it passes the bottom, get -1 from the life gauge ) and the other one waiting for the letters, which is to use for removal. ).
Both seem to need each processor to run on console in a real time and Message passing is necessary for matching letters.
Note that even though your application needs to perform seemingly parallel things, this does not automatically implies that you have to use multiple threads. Your task can be easily solved in a single thread, using an event loop for example.
Usually multi-threading is useful in just a couple of situations: 1) you need a computing performance, doing computations in parallel on multi-core system; 2) there are blocking operations (e.g. network or disc I/O) that affect other parts of the application (GUI responsiveness for instance).
You could use multithreading for this, but frankly, I wouldn't.
What you need to remember is that what a time period that's short enough to be simultaneous to a human is a small eternity to a computer. Or even a long one, depending on application.
What'll probably make your life a heck of a lot easier is something like this (pseudocode):
while (true) {
// moves letters down, spawns them at the top, checks if they've fallen off the screen
updateFallingLetters();
// polls for input, updates game state accordingly
checkIfIHaveInput();
// waits until one thirtieth or one sixtieth or whatever of a second has passed.
sleepUntilFrameRateAfterLastIWasHere();
}
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 7 years ago.
Improve this question
In genral I know about usage of break point, but would like to know how exactly does it work? how it can interrupt the executing code? how it provides user interface(break point) on executable code and why it normally allows only 6 break points.
Thanks!
There are usually two different kinds of breakpoint that a debugger can set: software breakpoints and hardware breakpoints.
A software breakpoint consists of replacing the instruction at the target address with a "break" instruction (e.g. int 3 on x86) and waiting for the CPU to execute it. When that instruction is hit, the CPU raises an exception and transfers control to the debugger. The upside is that you can define as many breakpoints as you want, but the downside is that this requires modifying the program in memory (which may not be possible for programs in read-only memory, or may cause the program to behave differently if it reads its own program memory).
The other kind, a hardware breakpoint, consists of setting a special debug register in the CPU to ask it to break when it hits a specified address. The CPU will automatically raise an exception when the program counter reaches that address. The upside is that no software modification is needed, but the downside is that this relies on a limited resource (debug registers) of which there may not be many. For example, x86 processors typically only have 4 debug address registers, so you can only set 4 hardware breakpoints at a time.
Debuggers typically pick a strategy depending on available resources (e.g. hardware breakpoints for the first 4 breakpoints and software breakpoints thereafter), although many can also be configured to force one particular type of breakpoint. For example, the popular debugger GDB has the hbreak command to explicitly create hardware breakpoints.
It depends upon the processor and the operating system. On Linux, a debugger is using the ptrace(2) system call, which the kernel executes with the help of some hardware features of the processors.