OSDev.org

While implementing liballoc I noticed that one of functions needed is supposed to lock the memory data structures. I was wondering if simply disabling interrupts would suffice. Sorry if this is a stupid question. However, the comments in liballoc.h mention disabling interrupts as an option for this function.

Does your OS support multiprocessing? If not, disabling interrupts is sufficient as a lock because it will prevent any other threads from running while the data structure is in use.

If your OS does support multiprocessing, disabling interrupts is not good enough. You need an actual lock variable that every processor can check to see whether the data structure is in use.

Thank you for the clarification. I had looked into spinlocks and muteness but heard they were not necessary for single processor systems and I just wanted to be sure. Thank you again!

FunnyGuy9796 wrote:Thank you for the clarification. I had looked into spinlocks and muteness but heard they were not necessary for single processor systems and I just wanted to be sure. Thank you again!

Spinlocks are only required for multicore systems. With only one processor core, cli/sti will solve the issues that spinlocks solve on multicore. Mutexes are required if you support multiple threads, regardless if you use one or many processor cores.

Lets say the computer were to have multiple cores and multiple threads. To my knowledge wouldn’t I need to access the APIC in order to detect this? Also, once the OS has knowledge of this how would I differentiate between which core or thread I am using? Would that involve interrupts as well? I am just trying to get an idea of how this works because I couldn’t find too much about it on the OSDev Wiki.

Your OS will need a scheduler, a task manager, and code to start multiple cores before you need to worry about spinlocks and multicore.

I started my OS project when the 386 processor was new, and multicore was not a topic. For synchronization with interrupt code, I used cli/sti. When I many years later wanted a multicore OS, I had to replace all cli/sti occurrences with spinlocks (among other things). This was a major problem that required several complete reverts before I had a stable multicore OS.

So, if you plan to eventually support multicore operation, you should try to mark-up or centralize cli/sti code, perhaps even providing an API for it that can be extended to a spinlock. A spinlock requires a variable. Then you might just place cli in the "acquire" call and sti in the "release" for now. Later, when you want multicore operation, you can add real spinlocks. Actually, I support both variants depending on number of active cores.

I think your first task is to implement threads & a scheduler on single core. If you have enough of the basic functionality (memory manager, interrupt handlers, fault handlers), that is.

When you can start threads & schedule them, you need synchronization primitives. I have critical sections and a signal/wait-for-signal API. Signal can be called from IRQs to wake-up threads. The synchronization primitives should be in place early, because you should not write lots of code without thinking of the code being shared by multiple threads, because this is not easily fixed later.

Thank you so much for the explanation! I will definitely keep this in mind while moving further.

FunnyGuy9796 wrote:Lets say the computer were to have multiple cores and multiple threads. To my knowledge wouldn’t I need to access the APIC in order to detect this?

Assuming your bootloader doesn't handle multiprocessing for you, you can detect available hardware threads using the ACPI MADT table or (in virtual machines) using the MP tables. These tables will also tell you what you need to know to enable the additional hardware threads.

FunnyGuy9796 wrote:Also, once the OS has knowledge of this how would I differentiate between which core or thread I am using?

Depending on exactly what information you're looking for, you might check the local APIC's ID register, or use the CPUID instruction, or use one of the segment registers (typically GS in 64-bit mode) as a pointer.

Alright, thank you again for the explanation!