OSDev.org

Hi I am now updating my kernel to support threads and multi core systems. Everything is almost designed but i have problems with threads stacks. When there is one thread per process I am just creating stack for it at the end of adress space but where should I put stacks for eg. second and third thread? I got idea of switching PT in process PD that describes stack of thread every time thread switch occures. But it will make some loses in system performance. Is there any other way for stack implementation?

Yeah, you just allocate pages at the top of address space somewheres to serve as thread stacks. You just can't grow such stacks beyond the space allocated for them.

You could allocate a completely new VM area (say 1MB) for each thread. I would advise simply swapping out the top of the address space during a thread switch though. Reduces loss of address space and is still quicker than a complete context switch.

Now is a perfect time to apply some emergency brakes very similar to the ones in a automobile.. really.

It is much simpler. If you have a working allocate page function in your kernel then this is the time to call it to allocate space for each new thread. You simply say:
ProcessInQuestion->ThreadInQuestion->stack = MyVirtualMemoryAllocatePageFunction(ForThisVDirectory, TheStackSizeIWant/4096);


Now you can dynamically allocate space for a stack no matter how many threads there are, or until you run out of memory. If I am not mistaken on most operating systems you can actually specify the thread's stack when making the system call or through the threading library to create a new one? I have done it in quite a few places, but can not place where I did..

Hmm, so you are saying Kevin that I should simply alocate spaces for stacks like memoy areas in one virtual memory space? But then thread A stack can go out of its limitations and overwrite memory of other thread stack or whole process data. To avoid this I need then to put missing pages on beginning and end of every stack to detect if it is going outside its limitations. Is this good idea ?

If you do implement it you will end up with something that has a rare benefit, costs CPU cycles, and increases coding complexity for the kernel.

In a threaded environment you generally want the threads to have global access to each other's data (as you are planning to do). My point is if a thread somehow went wild and starting corrupting data --- there should be a high chance it will corrupt critical data in the process that other thread's use , before it corrupts another thread's stack.

You got a disaster in any case, even if you do protect the stacks, so trying to do so could be just overboard.


I would this say is not a good idea right now. Just do not worry about it at the moment then later come back and try implementing the (below).

This seems like a okay idea to me, but you might add more complexity trying to detect the overflow of a stack -- since you have to find a range of pages that has free pages at the front and end. I would recommend using segmentation by making a descriptor for each thread's stack IF you really must have this stack overflow tolerance..

When I'm looking now on this from that side I think I don't really need that stack protection inside process. So if I put limitation on stack size (so creating thread will create stack of some size that cannot be resized) then idea of alocating stacks like normal memory areas fits to me .
Thanks for advices.