OSDev.org

Resting between iterations of my toy kernel development I would like to help other guys by answering different questions (theory / practical implementation). It would be nice to start a big interesting discussion.

I would like to base this discussion on my little piece of code: https://github.com/ababo/toy.
It covers many useful techniques and principles of kernel development. You can build it in Linux (tested on recent versions of Ubuntu) by gcc/clang, and run using qemu/kvm.

So I'm ready to answer your questions about OS kernel development. Just try...

Quick question: why have you implemented mutexes and not semaphores? As I'm sure you know, semaphores don't require much more effort and you can implement mutexes in terms of semaphores very easily.

Wow

much code
very OS
so much doge
such abstract
10/10

Thank you based god T_T

When did this forum become Jeopardy?

What do you do right after resuming a thread that is waiting on a mutex?
Which line could this statement be moved to?
Which 16 byte structure is then allocated on the heap only to be freed a couple of lines later on?

Quick question: why have you implemented mutexes and not semaphores? As I'm sure you know, semaphores don't require much more effort and you can implement mutexes in terms of semaphores very easily.

Yes, I have mutexes, but you're right, it's easy just to add a counter to implement semaphores. I just wanted to make sure that I can build synchronization primitives on top of my scheduler interface (and started with mutex as the simplest and widely used one).

What do you do right after resuming a thread that is waiting on a mutex?

I have a list of paused threads, each thread is a structure holding a CPU context (and other stuff). This list is guarded by a spinlock. If a new thread tries to acquire mutex, it checks this list. If it isn't empty the thread adds itself to list and pauses (removes itself from scheduling queue). When some thread releases the mutex, it removes a next waiting thread from the mutex list and inserts it to the scheduler queue, so next quantums it will be scheduled. This is simplified explanation, there are many details I have thrown off.

Which 16 byte structure is then allocated on the heap only to be freed a couple of lines later on?

Didn't exactly understand your question, but if you emphasize inefficiency in memory allocation, I can respond that all allocations are done through memory pool (fixed sized chunks, yes it's still not implemented, just a temporary stub directly calling malloc/free), so this should be very efficient.