OSDev.org

I've been thinking a lot about (pre-emptive) multi-threading, or task scheduling whatever the name of the game.

The question on my mind is: are there some ground rules on what to switch away from and what not? For example, I can see problems developing if the current process where to syscall into the kernel for memory management or talking to a device drive. What happens if the time-slice of the process was up and the timer event fired and we switch away to another task?

The device driver may have to deal with device timings to not leave a device in an unknown state (or something) whereas a memory manager might have some problems with re-entrancy when it was doing some bookkeeping.

Now you of course could simply disable interrupts for such calls but I have a feeling that this might be a bit too broad to disable interrupts for.

Another thought was what if we simply modify the return call so it returns to the scheduler when the kernel task is done and it normally would've returned to the calling process. We should be able to safely switch away to another process at that point and return it back to the proper place when the next time-slice for this project comes up.

I've read a lot in the OS FAQ (great stuff, thanks!) and some multi-threading links but didn't really find much if anything on this.

Does anyone have some thoughts and/or experience on this subject?

Thanks!

really what you are talking about is critical sections and the need for mutexes and/or semaphores. More complicated syncronization primitives can be made from these, but they provide the basics.

Anyway, if you are write code which is dealing with a device in a timing senstive manor, well you just might have the disable interrupts. In fact, on SMP you might even have to spinlock it too. This is your critical section, as in, things are broken if i EVER get interrupted in this block of code. Try to keep these to a minimum, but you will almost certainly have some.

Now if you are dealing with code that is more like two or more things accessing the same resource and you simply don't want them interfering with each other, well you need a mutex or a semaphore depending on what you want to do. This will allow other threads to continue, so long as they don't compete with your "held" resource. these are gonna be all over the place. Pretty much every data structure which can be accessed by 2 or more threads should have at the least a mutex.

modofying the return call is likely uneccessary, since after your critical section you will be preemptable again and you can do one of many things including just proceding until you are scheduled or explicitly yielding because you feel others need a chance to play . To be honest, once you have it so higher priority tasks can preempt lower priority ones, this will be a non-issue and you'll just let it continue until preempted.

proxy

Rob wrote: For example, I can see problems developing if the current process where to syscall into the kernel for memory management or talking to a device drive. What happens if the time-slice of the process was up and the timer event fired and we switch away to another task?

as the megaman (i mean Proxy ... shouldn't reply with small laptop screen) said, you usually want to use a semaphore to make sure everyone is using memory manager in proper time. Since you cannot tell how long memory bookkeeping might take (usually), you don't want interrupts to be disabled while doing this, but this may have the drawback of making memory allocator functions unavailable to interrupts.

Generally speaking, anything that is protected with a semaphore is not available when running interrupt code (or you might have nasty situations where interrupt code is waiting for the semaphore to be released by the interrupted thread). This is the very reason that leads to 'kernel threads' or 'tasklets' or 'bottom halves' (or whatever you want to call them

This actually makes quite a lot of sense. Thanks for your answers! I guess I was thinking a bit too low-level. Hadn't really thought about that kind of protection besides interrupts.

Thanks!