In message <42523776.4030804@gmx.de>"Oliver.Korpilla@gmx.de",
 writes:


>I think I've made an interesting observation: Fine grained locking and 
>preemption are not identical.
>
>Preemption can be realized as preempting system calls when no lock is 
>held to avoid global state corruption. Even with the biglock you can 
>implement preemption. [...]

I dont think so. You can pre-empt *only* when you can guarantee that
the kernel is *NOT* partway through some operation -- say,
read/modify-write of a memory location to update a shared-file-pointer
offset -- which must be atomic, as seen from userspace or by the
"kernel half" of other usrespace procesess.


The traditional answer, for a non-preemtive BSD kernel, is that the
only _truly_ safe points are when a system call is finished and is
about to return to userspace.

Or, as Soda-san observes, the scheduler and runqueue are protected by
the big-lock; so to implement pre-emption, you must move at least
those outside the biglock. But that doesn't really buy you pre-emtion;
all it really buys you is the ability to reschedule, even if one or
more processes is already in the kernel, either to reschedule or for
other reasons like I/O.  (Mendel Rosenblum once opined, many years
ago, that moving the scheduler out from a "giant lock" will get you
about 50% of the total gains obtainable from fine-grained locking. I
think Mendel was referring to time-shared 4-CPU sparc machines running
SunOS 4.1.x; I would add that it depends _very_ much on your workload.)