Race while modifying the task structures??

Well, this is a concern that has hit my head lately. When exposing the kernel structures to user tasks, I did not think about the race conditions that might arise. For example, when the task_table is being updated., (may be in the process of creation of a new driver task to handle a interrupt), if a spurious interrupt turns up, then it is possible that the task_table might be in a inconsistent state. Now, this calls for measures of avoiding race. Well, should cook up some hack to come about this.

I dont think that this problem would arise if the number of tasks actually manipulating these tables stays to a handful. However, this issue needs to be investigated.

Striking similarity between L4 and our Mexokernel

I just happened to notice a similarity between the L4 microkernel and the design that I've been working on., our dear Mexokernel. The L4 has a region of memory called the KIP (Kernel interface page). This page has some details which may be used by user programs. The L4 supports threads and address spaces. Each address space should have atleast one thread. Also, the creation of address space is done by a user land program. It creates a address space and configures it to run the first thread in it. Each address space can have multiple threads (there is a hard limit on this). Now, this multiple threads can modify their information table (user thread control block). These are in the user region., but the kernel uses these blocks to do the multitasking. Hence, a per address space, thread control is done completely in the code running in the address space.

There is a transcript of an interesting conversation about the L4 and hurd-l4 on #hurd@irc.freenode.net in here.

Now, in our case we dont have address spaces or threads. We have execution-states. We also export a set of pages containing data structures. But in our case, these data structures can be modified. Now, this is the beauty. I hope to avoid a number of task switches this way. Morover, this way we can actually give a lot of liberty to the userland code. However we should develop on this model to see more of this,