I would like to know if it's possible to access processor interrupts from a c++ code (I imagine I will need to use assembly code).
Here's the thing. I am used to working with embedded systems (PIC, ARM7 and Atmel processors) and I can program my interrupts without any problem (I use C). All registers are mapped, and all in all it's farely easy, depending on the application. Now I'm working with x86 and x64 architecture and I want (emphasis on WANT) to be able to do the same in these processors.
For example: I want to have a thread in c++ running a code that constantly verifies the key being pressed at the moment without pressing the enter key (cin, getchar, etc). I want to program a timer interrupt so I will be able to perform actions at an specific time. I understand that many of the things I want to do can be done via the operating system, but I really want to have the freedom to do so on my own.
Currently I'm using Linux (Ubuntu), but I will certainly be working with Windows soon, if that's an information needed to answer that question
For user-level processes, interrupts are replaced by signals. You can arrange to have a signal sent to your process by calling setitimer. But most likely, the best way to do what you're trying to do is one of two things:
Use an event loop. Basically, write your program as a giant loop that periodically checks to see if there's anything it needs to do. In the loop, check the time, check for keypresses, and so on. Do a little bit of work on whatever you need to do, and loop again.
Use threads. You can have a thread just to watch the time and trigger timer jobs. You can have a thread that blocks on a read to act like an interrupt when data arrives.
Likely it was drilled into your head that you do minimal work in the interrupt handler itself, typically just passing on information to other code that runs in a normal context. Well, the OS already does that part for you. You just have to write the code that waits for the interrupt handler (or whatever is needed) to detect and begin processing the event.
I want to have a thread in c++ running a code that constantly verifies the key being pressed at the moment without pressing the enter key (cin, getchar, etc).
So do that. That requires a thread and it requires changing the terminal's input mode to one that doesn't require an enter key. That has nothing to do with interrupts.
For Windows:
Windows does a very good job in hiding low level hardware access (like accessing cpu interrupts) and the reason is because the win kernel is using them for switching between processes and other internal stuff.
So you will need to write a driver to get direct hardware access or to get you code executed in an execution ring < 3 (user mode).
But for educational purposes you can use DOS or even a Windows DOS window, even interrupts are emulated. And of course you will be using some compiler like Borland C++ 3.x (dos 16bit). setvect and getvect are available there for interrupt hooking.
Related
I will be writing an interface in C++ that controls a large CNC machine and it will run on Windows. For safety reasons, I would like this process to run on it's own core so that it can run the process in real-time. If it shares a core with Windows, all of the Windows processes will be dealt with before my process is. Basically, how do I make sure either my process is always in the front of the processing queue, or how do I designate a core to run my process and leave the other core to handle Windows? Also, is there any way of seeing that my programming is run in real-time. AKA, this core is processing this program, but that core is not doing anything because we told out program not to run on it. Any input would be helpful.
There is no guarantee your process will be dealt with in real time. Windows does not do that. Since you mention safety, I will mention that if a lawsuit occurred you would be in deep trouble. Expert witnesses would testify that the design is inherently unsafe.
User control and display can be done in Windows but real time operations belong in dedicated hardware such as a PLC.
You can use SetThreadAffinityMask to restrict a thread to running on some subset of available processors/cores.
If you use SetThreadPriority and SetProcessPriorityClass to set a thread to real time priority, only other threads running at real time priority can interrupt it, effectively forcing other threads to run on other cores (unless you raise two or more threads to real time priority.
As an alternative, Windows Embedded Compact is a realtime priority-based OS that can make soft realtime guarantees (far better than Windows Vista/7). It's costly, but on par with other commercial RTOSes.
I'm not sure if anyone uses Borland c++ 3.1, but I have to do it.
I have a program which implements simple threads and changes context of those threads through timer interrupt.
I have an infinite loop and 2 threads that do their job and change between each other and main's thread. Their job is to produce some output, to write something on console.
Problem is that every time I run the program, different thing happens.
Sometimes it works for half a minute and it just stops writing what it should. Write just stops and there is no error and borland doesn't crash.
Sometimes it stops and borland crashes without message.
Sometimes it stops and borland crashes with message "illegal instruction"
Sometimes in the last line it writes before it stops are some weird characters that shouldn't be in output.
Is it the console that is "full" and borland acts weird?
What can be a problem?
If I remember correctly, is was not safe to write to the console (or use file I/O) under DOS when called from an interrupt. To do it properly, you must check something called "DOS re-entrancy flag" and only write to the console if it is zero (See http://cs.smith.edu/~thiebaut/ArtOfAssembly/CH18/CH18-3.html or search the web for more information)
In real and virtual 8086 modes programs aren't protected from each other. So, if your program screws something up, for example:
overwrites memory that does not belong to it (or to the appropriate thread in itself), including memory corruptions due to stack overflows in the program or its ISRs
fails to preserve (=save, then restore) CPU registers in any of its ISRs
changes hardware states to something unexpected to the rest of the system
alters timer frequency in obvious to the rest of the system ways
if it does any of that, it should be no surprise that something crashes or hangs or misbehaves in some other way.
I'm guessing that you're having issues 1 and/or 2 above. You can have a race condition there as well.
Unfortunately, without seeing any of your code we can't be of any more help. Think of it, it's like treating a new patient by phone.
I'm creating a concurrent memory reclamation algorithm in C++. Periodically, the stacks of executing mutator threads need to be inspected, so that I can see what references the threads are currently holding. In the process of doing this, I need to also check the registers of the mutator thread to check any references that might be in there.
Clearly many JVM's and C# vm's have no problem doing this as part of their garbage collection cycles. However, I haven't been able to find a definitive solution to this issue.
I can't quite tease apart what is going on in the Bohem garbage collector in order to inspect the root set, if you can (or know how its done), I'd really like to know.
Ideally I would be able to cause the mutator thread to be interrupted, and execute a piece of handler code which would report it's PC and also flush any register-based references into the stack, and then perhaps help finish the collection cycle. I believe that most compilers in most systems will automatically flush the registers when interrupt or signal handlers are called, but I'm not clear on the specifics, or how to access that data. It seems that separate stacks might be used for interrupt and signal handlers. Additionally, I can't find any information about how to target a particular thread, or how to send a signal. Windows does not seem to support this form of signaling anyway, and I would like my system to run on both Linux and Windows on x86-64 processors.
Edit: SuspendThread() is used in some situations, although safepoints seem to be preferred. Any ideas on why? Is there any way to deal with long-lasting I/O waits or other waits for kernel code to return?
I thought this was a very interesting question, so I dug into it a bit. It turns out that the Hotspot JVM uses a mechanism called "safepoints" which cause the threads of the JVM to cooperatively all stop themselves so that the GC can begin. In other words, the thread initiating GC doesn't forcibly stop the other threads, the other threads voluntarily suspend themselves by various clever mechanisms.
I don't believe the JVM scans registers, because a safepoint is defined such that all roots are known (I presume this means in memory).
For more information see:
HotSpot Glossary -- which defines safepoints
safepoint.cpp -- the source in HotSpot that implements safepoints
A slide deck that describes safepoints in some detail (look 10 slides or so in)
In regards to your desire to "interrupt" all threads, according to the slide deck I referenced above, thread suspension is "unreliable on Solaris and Linux, e.g., spurious signals." I'm not sure what mechanism even exists for thread suspension that the slides would be referring to.
On windows you should be able to get this done use SuspendThread (and ResumeThread) along with GetThreadContext (as Hans mentioned). All of these functions take handles to the specific thread you intend to target.
To get a list of all threads in the current process, see this(toolhlp32 works on x64, despite its bad naming scheme...).
As a point of interest, one way to flush registers to the stack on x86 is to use the PUSHAD assembly instruction.
I've often heard that using system("PAUSE") is bad practice and to use std::cin.get() instead. Now my understanding of system calls is that they take a string which they enter into a system command line and talk with the OS, so PAUSE is a DOS command that pauses the output in the command window. I assume this works similarly with Mac and unix with different keywords, and using system calls is discouraged because of a lack of cross OS compatibility. (If I'm wrong with any of this, please correct me)
my question is this: When is it appropriate to use system() calls? How should they be applied? When should they NOT be applied?
system("PAUSE") is certainly less than ideal. using a call to system creates a subprocess, which on windows is fairly expensive and in any case not terribly cheap on any operating system. On embedded systems the memory overhead is significant.
If there is any way to do it without much pain natively then do it. In the case of waiting for the user to press a single button, cin.get() will be very hard to beat. In this case, your applications process will just block on stdin, setting only a few flags visible to the kernel, and most importantly, allocates no new memory and creates no new scheduling entities, not even an interrupt handler.
Additionally, it will work the same on all operating systems with all c++ compilers, since it uses only a very basic feature of a very standard part of the language, rather than depend on anything the OS provides.
EDIT: predicting your concern that it doesn't matter if it's expensive because the whole idea is to pause. Well, first off, if its expensive, then it's going to hurt performance for anything else that might be going on. Ever notice (on windows) when one application is launching, other, already open apps become less responsive too? Additionally, your user might not be a live human, but rather another program working on behalf of a human user (Say, a shell script). The script already knows what to do next and can pre-fill stdin with a character to skip over the wait. If you have used a subprocess here, the script will experience a (noticeable to a human) delay. If the script is doing this hundreds (or hundreds of millions!) of times, a script that could take seconds to run now takes days or years.
EDIT2: when to use system(): when you need to do something that another process does, that you can't do easily. system() isn't always the best candidate because it does two things that are somewhat limiting. First, the only way to communicate with the subprocess is by command line arguments as input and return value as output. The second is that the parent process blocks until the child process has completed. These two factors limit the cases in which system is useable.
on unixy systems, most subprocesses happen with fork because it allows the same program to continue in the same place as two separate processes, one as a child of the other (which is hardly noticeable unless you ask for it from the OS). On Linux, this is especially well optimized, and about as cheap as creating a pthread. Even on systems where this is not as fast, it is still very useful (as demonstrated by the apache process-pool methodology) (unavailable on windows/link to unix docs)
other cases (on windows too!) are often handled by popen or exec family of functions. popen creates a subprocess and a brand new pipe connecting to the subprocesses' stdin or stdout. Both parent and child processes can then run concurrently and communicate quite easily. (link to windows docs/link to unix docs)
exec* family of functions (there are several, execl, execv and so on) on the other hand causes the current program to be replaced by the new program. The original program exits invisibly and the new process takes over. When then new process returns, it will return to whatever called the original process, as if that process had returned at that point instead of vanishing. The advantage of this over exit(system("command")) is that no new process is created, saving time and memory (though not always terribly much) (link to windows docs /link to unix docs)
system could plausibly be used by some scripted tool to invoke several steps in some recipe action. For example, at a certain point, a program could use system to invoke a text editor to edit some configuration file. It need not concern itself too much with what happens, but it should certainly wait until the user has saved and closed the editor before continuing. It can then use the return value to find out if the editing session was successful, in the sense that the editor actually opened the requested file (and that the editor itself existed at all!), but will read the actual results of the session from the edited file directly, rather than communicating with the subprocess. (link to windows docs/link to unix docs)
System calls are sent to the shell or command line interpreter of the OS (dos, bash, etc) and its up to the shell to do what it wants with this command.
You would avoid using these kind of calls as it would reduce your programs portability to work with other operating systems. I would think only when you are absolutely sure that your code is targeting a specific OS that you should use such calls.
But my question is this: When is it appropriate to use system() calls? How should they be applied?
When you can't do the thing you're trying to do with your own code or a library (or the cost of implementing it outweighs the cost of launching a new process to do so). system() is pretty costly in terms of system resources compared to cin.get(), and as such it should only be used when absolutely necessary. Remember that system() typically launches both an entire new shell and whatever program you asked it to run, so thats two new executables being launched.
By the way, system() call should never be used with binaries with SUID or SGID bit set, quoting from the man page:
Do not use system() from a program with set-user-ID or set-group-ID
privileges, because strange values for some environment variables
might be used to subvert system integrity. Use the exec(3) family of
functions instead, but not execlp(3) or execvp(3). system() will not,
in fact, work properly from programs with set-user-ID or set-group-ID
privileges on systems on which /bin/sh is bash version 2, since bash 2
drops privileges on startup.
system() is used to ask the operating system to run a program.
Why would your program want the operating system to run a program? Well there are cases. Sometimes an external program or operating system command can perform a task that is hard to do in your own program. For example, an external program may operate with elevated privileges or access propriety data formats.
The system() function, itself, is fairly portable but the command string you pass it is likely to be very platform-specific -- though the command string can be pulled from local configuration data to make it more platform-agnostic.
Other functions like fork(), exec*(), spawn*() and CreateProcess() will give you much more control over the way you run the external program, but are platform-specific and may not be available on your platform of choice.
system("PAUSE") is an old DOS trick and is generally considered to be fairly grotty style these days.
As far as i know system("PAUSE") is a windows only thing, and that is why it is frowned upon.
Just curious. How does actually the function Sleep() work (declared in windows.h)? Maybe not just that implementation, but anyone. With that I mean - how is it implemented? How can it make the code "stop" for a specific time? Also curious about how cin >> and those actually work. What do they do exactly?
The only way I know how to "block" something from continuing to run is with a while loop, but considering that that takes a huge amount of processing power in comparison to what's happening when you're invoking methods to read from stdin (just compare a while (true) to a read from stdin), I'm guessing that isn't what they do.
The OS uses a mechanism called a scheduler to keep all of the threads or processes it's managing behaving nicely together.
several times per second, the computer's hardware clock interrupts the CPU, which causes the OS's scheduler to become activated. The scheduler will then look at all the processes that are trying to run and decides which one gets to run for the next time slice.
The different things it uses to decide depend on each processes state, and how much time it has had before. So if the current process has been using the CPU heavily, preventing other processes from making progress, it will make the current process wait and swaps in another process so that it can do some work.
More often, though, most processes are going to be in a wait state. For instance, if a process is waiting for input from the console, the OS can look at the processes information and see which io ports its waiting for. It can check those ports to see if they have any data for the process to work on. If they do, it can start the process up again, but if there is no data, then that process gets skipped over for the current timeslice.
as for sleep(), any process can notify the OS that it would like to wait for a while. The scheduler will then be activated even before a hardware interrupt (which is also what happens when a process tries to do a blocking read from a stream that has no data ready to be read,) and the OS makes a note of what the process is waiting for. For a sleep, the process is waiting for an alarm to go off, or it may just yield again each time it's restarted until the timer is up.
Since the OS only resumes processes after something causes it to preempt a running process, such as the process yielding or the hardware timer interrupt i mentioned, sleep() is not very accurate, how accurate depends on the OS or hardware, but it's usually on the order of one or more milliseconds.
If more accuracy is needed, or very short waits, the only option is to use the busy loop construct you mentioned.
The operating system schedules how processes run (which processes are eligible to run, in what order, ...).
Sleep() probably issues a system call which tells the kernel “don't let me use the processor for x milliseconds”.
In short, Sleep() tells the OS to ignore the process/thread for a while.
'cin' uses a ton of overloaded operators. The '>>', which is usually right bit-shift, is overloaded for pretty much every type of right-hand operand in C++. A separate function is provided for each one, which reads from the console and converts the input into whichever variable type you have given. For example:
std::cin::operator>> (int &rhs);
That's not real C++ — I haven't worked with streams and overloading in a while, so I don't remember the return type or the exact order of arguments. Nevertheless, this function is called when you run cin >> an integer variable.
The exact underlying implementation depends on the operating system.
The answer depends on the operating system, but generally speaking, the operating system either schedules some other code to run elsewhere in another thread, or if it literally has nothing to do, it gets the CPU to wait until a hardware event occurs, which causes the CPU to jump to some code called an interrupt handler, which can then decide what code to run.
If you are looking for a more controlled way of blocking a thread/process in a multi-threaded program, have a look at Semaphores, Mutexes, CriticalSections and Events. These are all techniques used to block a process or thread (without loading the CPU via a while construct).
They essentially work off of a Wait/Signal idiom where the blocked thread is waiting and another process signals it to tell it to start again. These (at least in windows) can also have timeouts, thus providing a similar functionality to Sleep().
At a low level, the system has a routine called the "scheduler" that dispatches the instructions from all the running programs to the CPU(s), which actually run them. System calls like "Sleep" and "usleep" match to instructions that tell the scheduler to IGNORE that thread or process for a fixed amount of time.
As for C++ streams, the "cin" hides the actual file handle (stdin and stdout actually are such handles) you're accessing, and the ">>" operator for it hides the underlying calls to read and write. Since its an interface the implementation can be OS-specific, but conceptually it is still doing things like printf and scanf under the hood.