preemptible kernel

Quoted 5 lines

I see your point here, but need to think about it. One question:
isn't it the case that the alternative to using synchronize_kernel() is to protect the read side with explicit locks, which will themselves suppress preemption? If so, why not just suppress preemption on the

Quoted 6 lines

side in preemptible kernels, and thus gain the simpler implementation of synchronize_kernel()? You are not losing any preemption latency compared to a kernel that uses traditional locks, in fact, you should improve latency a bit since the lock operations are more expensive than are simple increments and decrements. As usual, what am I missing here? ;-)

Already preempted tasks.

Quoted 5 lines

Another approach would be to define a "really low" priority that noone other than synchronize_kernel() was allowed to use. Then the UP implementation of synchronize_kernel() could drop its priority to this level, yield the CPU, and know that all preempted tasks must have obtained and voluntarily yielded the CPU before synchronize_kernel

Quoted 1 line

gets it back again.

Or "never", because I'm running RC5 etc. 8(.

Quoted 1 line

Already preempted tasks.

But if you are suppressing preemption in all read-side critical sections, then wouldn't any already-preempted tasks be guaranteed to -not- be in a read-side critical section, and therefore be guaranteed to be unaffected by the update (in other words, wouldn't such tasks not need to be waited for)?