spinlock semantics

[Matthew Dillon]

:Hi,
:
:While reading about DragonFlys locking primitives in a quest to try to
:understand which kind of lock best applies in each situation, I found
:the following at the spinlock(9) manpage.
:
:"If you wish to disable FAST interrupts and IPIs you need to enter a
:critical section prior to obtaining the spinlock."
:
:But then, on the mailing list archive, I found a message [1] where one
:can read the following with regards to spinlocks:
:
:"Automatically enters a critical section."
:
:So, naturally, my question is which statement is true? Looking at the
:implementation, i don't see any calls to crit_* there, so I assume
:that the manpage is correct.
:
:Thanks,
:Nuno
:
:[1] http://leaf.dragonflybsd.org/mailarchive/kernel/2006-11/msg00026.html

    spinlocks increment and decrement mycpu->gd_spinlocks_rd/wr.
    This prevents thread preemption from occuring (lwkt_thread.c line 846).

    This means that a FAST interrupt can still operate, and any threaded
    interrupt (which is basically all interrupts except the clock interrupt)
    will still be scheduled, but will NOT be able to preempt the current
    thread.

    It's kinda like a poor-man's critical section.  It has a few issues
    the main one being that it does not currently check to see if a yield
    is needed after the last spinlock is released.  I wanted the spinlock
    path to be as fast as possible.

    A critical section is a more encompassing feature.  A critical section
    will cause the interrupt itself to be deferred if it occurs on the
    cpu in question... for example, an interrupt which schedules a
    thread during a spinlock will not preempt, but an interrupt which occurs
    during a critical section won't even schedule the interrupt thread in
    the first place.  It will just mark the interrupt as pending in the
    machine-dependant portion of the globaldata structure, mask the
    interrupt, and return.

    Thus the scheduler itself can use a critical section to protect against
    reentrancy.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>