Understanding the FreeBSD locking mechanism

[Chris Torek]

>Signal trampolines never were put on the kernel stack ...

Oops, right, not sure why I was thinking that.  However I would still
prefer to have libc supply the trampoline address (the underlying
signal system calls can do this, since until you are catching a
signal in the first place, there is no need for a known-in-advance
trampoline address).

>Kstack still contains the remnants of the uarea, renamed to (per-thread)
>pcb. There is no much sense in the split of struct thread vs. struct
>pcb, but it is historically survived up to this moment, and clearing
>things up requires too much MD work.
>My opinion is that pcb on kstack indeed only eats the space and better be
>put into td_md.

That would be good.

>> When an interrupt arrived, as long as it was not interrupting
>> another interrupt, the system would get on a separate "interrupt
>> stack" ...

No, this is not a case, at least on x86.

On VAX, and (emulated without hardware support) in my SPARC port,
it was. :-)

>There, 'normal' interrupts and exceptions reuse the current thread
>kstack ...

I never liked this very much, but if it's faster on x86, it's not
unreasonable.  And without hardware support (or if the TSS switch
is too slow) it's OK.

>>  * In a "critical section", we wish to make sure that the current
>>    thread does not migrate from one CPU to another.
>>    ...  we block interrupts for short durations here as well (actually
>>    when *leaving* the critical section, where we check to see if
>>    the scheduler would *like* us to migrate).

>This is not true, both in explanation of intent, and in the implementation
>details.

Ah, and I see you added a compiler_membar and some comments here
recently.  I did indeed misread the micro-optimization.

>You probably mixed critical_enter() and spinlock_enter() there.
>The later indeed disables interrupt and intended to be used as part
>of the spinlock (spin mutexes) implementation.

What I meant was that it's a dreadful error to do, e.g.:

	critical_enter();
	mtx_lock(mtx);
	...
	mtx_unlock(mtx);
	critical_exit();

but the other order (lock first, then enter/exit) is OK.  This
is similar to the prohibition against obtaining a default mutex
while holding a spin mutex.

Chris