OSDev.org

Hi,

I'm going to implement preemptive multitasking. Now if I disable interrupts while in kernel space (which makes my kernel non re-entrant, if I understand it well), then everything should be ok without synchronisation in te kernel (except synchronisation between processes, ofc)?

Am I right? Is this a good idea?

Thanks

No.

Software traps (eg, a page fault) may still fire.

And don't forget multi-CPU computers.

That's a BKL (Big Kernel Lock) or BGL (Big Giant Lock), which linux and bsds want to get rid off (with more or less success).

Some readings:
http://kernelnewbies.org/BigKernelLock
http://www.makelinux.co.il/books/lkd2/ch09lev1sec8

Hmm.. I understand the problem, and I understand it's something to avoid. I'll start learning more about synchronisation techniques.

A related question...

I have a log()-functions, which prints a text, character per character, to the bochs debug port. If an interrupt occured during the printing, and the interrupt used the log()-function itself, the output got mixed.

So I first thought: I'll protect the log-function with a spinlock. Ofcourse, this made my system hang, since at startup there is no timer interrupt (and there were no processes yet): the interrupt took over control, entered the spinlock, and couldn't leave it...

In my opinion, there is only one solution: disable interrupts while using log(). Is this good, or are there other synchronisation techniques for solviing this problem? Because later, when there is scheduling, a spinlock would be fine there?

It's not a good idea to lock for IO access.

If you have threads, I suggest to lock -> memcpy -> unlock, and have that thread to poll / wait signal and do the actual IO.

turdus wrote:That's a BKL (Big Kernel Lock) or BGL (Big Giant Lock), which linux and bsds want to get rid off (with more or less success).

Turning interrupts off doesn't mean you have a BKL. The BKL is about protecting multiple CPUs from each other, whereas disabling interrupts protects a single CPU from, well, being interrupted.