The issues and solutions for implementing the required execution model in preemptive kernels are similar to those for multiprocessor kernels: basically, locks are used to protect the component's code. Again, the locking granularity can be global or per-component (or anything in between, as the OS desires). However, in this case, a blocking lock must be used rather than a simple spin lock because the lock must continue to be held if a process running the component's code is preempted. (Note the distinction between OS-level ``blocking,'' which can occur at any time during execution of the component's code but is made invisible to the component's code through the use of locks; and component-level ``blocking,'' which only occurs when a component calls a blocking function.)
An alternative solution to the preemption problem is simply to disable preemption while running the component's code. This solution is likely to be simpler in terms of implementation and to have less overhead, but it may greatly increase thread dispatch latency, possibly defeating the purpose of kernel preemption in the first place.