I'm studying the xv6 context switch on Operating Systems: Three Easy Pieces book. I can not fully understand the Saving and Restoring Context section of Chapter 6 (page 8).
Why there are two types of register saves/restore that happen during the Context Switch protocol?
What is the difference between the mentioned user registers and kernel registers?
What is the meaning of:
By switching stacks, the kernel enters the call to the switch code in the context of one process (the one that was interrupted) and returns in the context of another (the soon-to-be-executing one).
Why there are two types of register saves/restore that happen during the Context Switch protocol?
Assuming you are talking about p. 10. The text is a bit misleading (but not as nearly bad as I have seen in some books). They are comparing register save in interrupts those to context switches. It's really not a good comparison.
Register saves in interrupt handling is done the same way as you do it in a function call (and not like it is done in a context switch). You have to preserve any register values you are going to muck with at the start interrupt handling then restore them before the interrupt handler return. You are only dealing with general purpose registers as well (ie not process control registers).
Register save in context switches are done en-masse. All the process's registers get saved at once. An interrupt service routine might save 4 registers while a context switch might save more than 30.
What is the difference between the mentioned user registers and kernel registers?
Some registers are accessible and modifiable in user mode. The general purpose registers would certainly be user registers. The processor status is a mixed bag because it can be read in user mode, it can be modified in some ways in user mode by executing instructions but it is generally read only in user mode. You might call that a user register or might not.
There are other registers that are only accessible in kernel mode. For example, there will be registers that define the process's page table. Other registers will define the system dispatch table.
Note here the only some of the kernel mode registers are process registers (e.g. those setting up page tables) and need to be saved and restored with the process. Other kernel registers are system wide (e.g. those for timers and the system dispatch table). Those do not change with the process.
By switching stacks, the kernel enters the call to the switch code in the context of one process (the one that was interrupted) and returns in the context of another (the soon-to-be-executing one).
This is a little bit misleading in the excerpt but might make more sense if I read the book carefully.
A process context switch requires changing all the per-process registers to a block whose structure is defined by the CPU. What I find misleading in your excerpt is that the context switch involves more than just switching stacks.
Typically a context change looks something like:
SAVE_PROCESS_CONTEXT_INSTRUCTION address_of_the_current_process_context_block
LOAD_PROCESS_CONTEXT_INSTRUCTION address_of_the_next_process_context_block
As soon as you load a process context you are in the new process. That switch includes changing the kernel mode stack.
Some operating systems use terminology in their documentation that implies interrupts (especially) and (sometimes) exceptions being handlers are not done in the context of a process. In fact, the CPU ALWAYS executes in the context of a process.
As soon as you execute the context switch instruction you are in the new process BUT in an exception or interrupt handler in kernel mode. The change in the kernel stack causes the return from the exception or interrupt to resume the new process's user mode code.
So you are already in the context of the process with the PCB switch.The resulting change in the kernel mode stack pointer (ie establishing a new kernel mode stack) causes return from the exception or interrupt to pick up where the new process was before it entered kernel mode (via exception or interrupt)
Related
I am building a simple OS for learning purposes and I am (currently; I followed different tutorials earlier and customized something by myself) following this tutorial for enabling paging. I'm using QEMU instead of Bochs as my emulator.
If I keep paging disabled everything works fine (even the very basic kmalloc() I implemented), but as soon as I set the PG bit in the cr0 register (i.e. enable paging), everything crashes and QEMU reboots: I suspect that some of the structures (i.e. page directory, page tables, etc.) I have are not created or loaded properly, but I have no way of checking.
I've been trying to solve this problem since a while now, but haven't found a solution. Can anyone see where my mistake is?
Here you can find my complete code: https://github.com/davidedellagiustina/ScratchOS (commit 83b5c8c). Paging code is located in src/cpu/paging.*.
Edit: Setting up a super-basic page directory following exactly this tutorial results in working code. Basing on this simple example, I'm trying to build up the more complex structures (i.e. page_t, page_table_t, page_directory_t) in order to understand the mistake.
In general:
pointers should be for virtual addresses only (and should never be used for physical addresses)
physical addresses should probably be using a typedef (e.g. like typedef uint32_t phys_address_t) so that later (when you want to support PAE/Physical Address Extensions) you can change the type (e.g. use typedef uint64_t phys_address_t instead) without breaking everything. This also means you get compile-time warnings/errors when you make silly mistakes (e.g. using a virtual address/pointer where you need a physical address/unsigned integer).
almost all of the kernel should be using pointers/virtual addresses for everything. Physical addresses are only used by some device drivers (for bus mastering/DMA) and for the physical memory management itself (to allocate physical pages for page tables, etc; before mapping them into a virtual address space). This includes high level memory management ("kmalloc()" should return a void * pointer and not a physical address).
during boot, there's a small period of time when none of the kernel's normal code can work because it uses virtual addresses and paging hasn't been initialized yet. To minimize the size of this period of time (and code duplication caused by having 2 versions of functions - one for "before paging initialized" and another for "after paging initialized") you want to initialize paging as soon as possible; either with a dedicated piece of assembly language startup code that's executed before "main()" (possibly using "statically allocated at compile time" memory in the kernel's ".bss" section for the page directory and page tables), or in the boot loader itself (which is cleaner and more powerful/flexible). Things like setting up a valid kernel stack, and initializing (physical, virtual then heap) memory management, can/should wait until after paging has been initialized.
for identity mapping; you'd only need 2 loops (one to create page directory entries and another to create all page table entries), where both loops can be like this (just with different initial values in eax, ecx and edi):
.nextEntry:
stosd
add eax,0x00001000
loop .nextEntry
identity mapping isn't great. Normally you want the kernel at a high virtual address (e.g. 0xC0000000) with an area of "deliberately not used to catch NULL pointers" at 0x0000000, and user-space (processes, etc) using normal virtual addresses between them (e.g. maybe starting at virtual address 0x00400000). This makes it annoying for the code that initializes paging and the kernel's linker script (which is why it's cleaner to initialize paging in the boot loader and avoid the mess in the kernel). For this case; you will need to temporarily identity map one page (the page containing the final "mov cr0" that enables paging and the jmp kernel_entry that transfers control to code/the kernel at a higher address), and will want to delete that temporarily identity mapped page after kernel's main is started.
you will need to become "very familiar" with the debugging capabilities of your emulator. Qemu has a log that can provide very useful clues, and includes a built in monitor that offers a variety of commands (see https://en.wikibooks.org/wiki/QEMU/Monitor ). You should be able to replace the "mov cr0" (that enables paging) with an endless loop (.die: jmp die), then use the monitor to stop the emulator after it reaches the endless loop and inspect everything (contents of cr3, contents of physical memory) and find out what is wrong with the page directory or page table entries (and do similar immediately after paging is enabled to inspect the virtual address space before your code does anything with it). Qemu also allows you to attach a remote debugger (GDB).
I found out I was missing all the flags in the page directory entries (and especially the read/write and the kernel mode ones), as I was putting there just the page table address. I will keep my repository public and I will continue the development from now on, in case anyone needs it in the future.
Edit: Also, I forgot to initialize all the pages (with address and presence bit) when I created a new page table.
I'm working on a programm (notifyfs) which takes care for caching of directory entries and watching the underlying filesystem for changes. The cache is stored in shared memory, (gui) clients can make use of the cache very easily.
Communication between server (notifyfs) and clients can go using a socket or via the shared memory self, by sharing a mutex and condition variable.
When a client wants to load a directory it does the following:
a. select a "view", which is a data struct in shared memory, which consists of a shared mutex, conditionvariable and a small queue (array), to communicate add/remove/change events with the client.
b. the client populates his/her model with what it already finds in the shared memory
c. send a message to the server with a reference to the view, and an indication to the path it wants to load its contents. This maybe a path, but if possible the parent entry.
d. server receives the message (does some checks), sets a watch on the directory, and synces the directory. When the directory has not yet been in the cache this means that every entry it detects is stored in the cache. While doing so it signals the view (the data in shared memory) an entry is added, and it stores this event in the array/queue.
e. the gui client has a special thread watching this view in shared memory constantly for changes using the pthread_cond_wait call. This thread is a special io thread, which can send three signals: entry added, entry removed and entry changed. The right parameters it reads from the array queue: a reference to the entry, and what the action is. These three signals are connected to three slots in my model, which is based upon a QStandardItemModel.
This works perfectly. It's very fast. When testing it I had a lot of debugging output. After removing these to test it without this extra slow io, it looks like the QTreeView can't catch up the changes. When loading a directory it loads two third of it, and when going to load another directory, this gets less and less.
I've connected the different signals from the special thread to the model using Qt::QueuedConnection.
Adding a row at a certain row is done using the insertRow(row, list) call, where row is of course the row, and list is a QList of items.
I've been looking to this issue for some time now, and saw that all the changes are detected by the special io thread, and that the signals are received by the model. Only the signal to the QTreeView is not received somehow. I've been thinking, do I have to set the communication between the models signal and the receiving slot of the treeview also to "Qt::QueuedConnection"? Maybe something else?
suggested in the reactions was to put the model in a special thread. This was tempting, but is not the right way to solve this. The model and the view should be in the same thread.
I solved this issue by doing as much as possible when it comes to providing the model with data by the special io thread. I moved some functions which populated the model to this special io, and used the standard calls to insert or remove a row. That worked.
Thanks to everyone giving suggestions,
Stef Bon
I have a process, and I'd like to check whether it is running or not, and take a decision in that direction, i.e., I'd like to check for running instances of this application, from another instance.
I can have 2 instances of the application running, dealing with 2 types of data. When a 3rd instance opens, it needs to check if another instance of its type ( from the 2 types already created ) is already running. If so, the new one needs to close down and send a message to the already running instance of its type.
Because of this, I think QtSingleApplication will not work.
I wish to create a System wide mutex and have the check done that way, but I've not seen any System wide mutex in Qt.
There is QMutex, which is only for threads of an application.
There is also something called QSystemMutex when I search online, but I suppose that's a custom solution? I didn't find it in my Qt installation or the assistant.
So is there any way I can create a System wide mutex using Qt, please?
Mutexes are defined to be used as a object in one process. You are looking for a solution outside the process.
An simple solution would be to use the filesystem. Create a file and delete it when the process stops. This can be harder though when multiple processes are running from different directories or when the application crashes.
An more advanced solution is to use a shared memory object. These objects exist outside the process, and can be checked and modified from any process. An example on shared memory for QT can be found here:
http://doc.qt.digia.com/4.7-snapshot/ipc-sharedmemory.html
You can definitely do that with QtSingleApplication. Nothing obliges you to terminates if the application is already running. You can define a bootstrap protocol on top of what QtSingleApplication offer you, ie you use its api as a locking primitive.
What you can do is send a message with a specific type to the running instance, for example the string representation of the type. It is simple: You send a message to the running instance and he tells you if you are welcome or not.
Each time an application starts, it listen to messages (even if there is one running). He can ack only one message if the type differs his.
If there is no application running he goes straight to doing his job.
If there is an application running, he send an hello message (his type for instance) and wait for ACK, NACK or timeout. You decide what to do if it timeouts.
If you are waiting for a reply and you recieve an hello, you refuse.
ps: What you describe is not exactly a mutex. the following code
int main(int argc, char **argv) {
QtSingleApplication app(argc, argv);
if (app.isRunning())
return 0;
//blah blah blah
}
is already a mutex.
According to wikipedia:
Shared locks are sometimes called "read locks" and exclusive locks are sometimes called "write locks".
Can you explain the reasoning behind the terms "shared" and "exclusive"?
I wrote this answer down because I thought this would be a fun (and fitting) analogy:
Think of a lockable object as a blackboard (lockable) in a class room containing a teacher (writer) and many students (readers).
While a teacher is writing something (exclusive lock) on the board:
Nobody can read it, because it's still being written, and she's blocking your view => If an object is exclusively locked, shared locks cannot be obtained.
Other teachers won't come up and start writing either, or the board becomes unreadable, and confuses students => If an object is exclusively locked, other exclusive locks cannot be obtained.
When the students are reading (shared locks) what is on the board:
They all can read what is on it, together => Multiple shared locks can co-exist.
The teacher waits for them to finish reading before she clears the board to write more => If one or more shared locks already exist, exclusive locks cannot be obtained.
It's pretty straightforward. Read locks are also known as shared locks because more than one process can read at the same time. The point of a read lock is to prevent the acquisition of a write lock by another process. By contrast, a write lock inhibits all other operations while a write operation completes which is why it is described as exclusive.
So a read lock says "you can read now but if you want to write you'll have to wait" whereas a write lock says "you'll have to wait".
I realise you're researching in support of your studies, but I can't resist the urge to lecture.
Incompetent use of locking is a primary cause of performance headaches. Use of a locking system that differentiates read and write locks is a good start, but careful design can sometimes eliminate much of the need to lock. For example, session state should never be held in one global collection per element of state.
I have actually seen this done. It's an atrocious design, causing boxing and a change to a collection for every last change to session state, entailing a protracted write lock. Overheads were crippling, effectively reducing the server to single threaded behaviour.
Simply aggregating all the session state into a struct was a huge improvement. Changes to session state merely changed the values of members of a session's state struct. Since no other session had occasion or even opportunity to directly reference a session's state, the only collection being updated was the list of sessions. As a result, locking was completely unnecessary during a sesssion, only at the start and end, and throughput rose by a factor of 3000.
The other common locking scenario is resources shared between threads of a user application. Most modern frameworks address this using messages rather than locks; when you "transition to the UI thread" you are actually queueing a message containing a function pointer and some parameters (or a delegate and a stack frame depending on implementation).
An exclusive or write lock gives a process exclusive access for writing to the specified part of the file. While a write lock is in place, no other process can lock that part of the file.
A shared or read lock prohibits any other process from requesting a write lock on the specified part of the file. However, other processes can request read locks.
More on that : http://www.gnu.org/software/libc/manual/html_node/File-Locks.html
Principle same on the database side as well. As per the Oracle documentation
Exclusive lock mode prevents the associated resource from being shared. This lock mode is obtained to modify data. The first transaction to lock a resource exclusively is the only transaction that can alter the resource until the exclusive lock is released.
Share lock mode allows the associated resource to be shared, depending on the operations involved. Multiple users reading data can share the data, holding share locks to prevent concurrent access by a writer (who needs an exclusive lock). Several transactions can
acquire share locks on the same resource.
Exclusive lock doesn't allow read and write operations.
Shared lock allows only read operation.
Registers are the fastest type of memory. On a context switch, registers have to save their data somewhere and then they have to load the right data into the registers for that particular context. This could be a slow process if the registers aren't storing and retrieving their data from other registers.
But I'm not sure what registers use to store and retrieve data for context switches. I don't think they use other registers. What do they use?
Also, about how often does a context switch take place?
A bit of googling yields this fairly in-depth wiki article on context switching.
How often this happens depends on the operating system; on Linux, it depends on what scheduler algorithm is in fashion this week, and what parameters it's been compiled with.