Questions about preemptive multitasking

[mrjbom]

I have several questions related to preemptive multitasking.

First question:
The process makes a request to the memory Manager to allocate a page, while the memory Manager is running, an interruption occurs and the scheduler switches to another task. will the memory Manager continue to work correctly after returning to the process that called it? As far as I understand, during the process switching, the scheduler should remember all its registers and when it returns, the processor will continue working from the place where it was interrupted thanks to instruction pointer. Right?

Second question(extremely difficult for reading)):
Let's imagine that there are 2 processes(A and B) and they make a request for memory allocation.
In the memory Manager, when allocating, there are various variables (for example, there is a variable that stores the number of pages that follow each other at the address).
Process A tries to get memory, it calls the function that searches for pages, while running the memory allocation function remembers information about the found pages, but does not have time to finish the work correctly(the task was switched), process B makes a request for page allocation, it marks the desired pages and successfully allocates pages, the process switches, process A continues to allocate memory, but because of process B(which has already occupied that memory area), it allocates it a second time, how to avoid such situations? How real is this problem?

Third question:
What is the optimal frequency to set for IRQ0?
I set 50 Hz(20 ms), every tick I want to change the task.

Where can I read about implementing preemptive multitasking?

[iansjack]

You will find many of your questions discussed here: http://pages.cs.wisc.edu/~remzi/OSTEP/

[AndrewAPrice]

1) Correct

2) Mutexes.

Wrap the code that you only want executed by one thread at a time in a mutex. A simple mutex could be:

Code: Select all

typedef int mutex_t;

void lock(mutex_t* mutex) {
  int mutex_state = 1;
  while (true) {
    atomic_exchange(mutex, &mutex_state);
    if (mutex_state == 0) {
      return;
    } else {
      yield();
    }
  }
}

void unlock(mutex_t* mutex) {
  *mutex = false;
}

A more complicated mutex could put the thread to sleep, and wake the next queued thread on unlock.

Interrupts get temporarily turned off while in an interrupt handler (unless you turn them back on), so if you put your allocate functions, scheduling functions, etc. inside system calls you get these mutexes for free on a single core system (thus, microkernels tend to have a bit of an easier job, because you only invoke kernel code via syscalls and interrupts.)

3) A 50Hz clock is perfectly fine. I'm thinking of at some point switching from regular intervals to one shot timers to solve the partial timeslice problem.