OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 5:26 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Locking Memory Data Structures
PostPosted: Thu Mar 02, 2023 3:24 pm 
Offline
Member
Member

Joined: Tue Sep 13, 2022 9:29 pm
Posts: 61
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.


Top
 Profile  
 
 Post subject: Re: Locking Memory Data Structures
PostPosted: Thu Mar 02, 2023 3:39 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5100
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.


Top
 Profile  
 
 Post subject: Re: Locking Memory Data Structures
PostPosted: Thu Mar 02, 2023 3:41 pm 
Offline
Member
Member

Joined: Tue Sep 13, 2022 9:29 pm
Posts: 61
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!


Top
 Profile  
 
 Post subject: Re: Locking Memory Data Structures
PostPosted: Fri Mar 03, 2023 3:32 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
 Post subject: Re: Locking Memory Data Structures
PostPosted: Fri Mar 03, 2023 6:11 am 
Offline
Member
Member

Joined: Tue Sep 13, 2022 9:29 pm
Posts: 61
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.


Top
 Profile  
 
 Post subject: Re: Locking Memory Data Structures
PostPosted: Fri Mar 03, 2023 9:45 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Last edited by rdos on Fri Mar 03, 2023 9:51 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Locking Memory Data Structures
PostPosted: Fri Mar 03, 2023 9:47 am 
Offline
Member
Member

Joined: Tue Sep 13, 2022 9:29 pm
Posts: 61
Thank you so much for the explanation! I will definitely keep this in mind while moving further.


Top
 Profile  
 
 Post subject: Re: Locking Memory Data Structures
PostPosted: Fri Mar 03, 2023 1:28 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5100
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.


Top
 Profile  
 
 Post subject: Re: Locking Memory Data Structures
PostPosted: Fri Mar 03, 2023 1:29 pm 
Offline
Member
Member

Joined: Tue Sep 13, 2022 9:29 pm
Posts: 61
Alright, thank you again for the explanation!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 72 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group