> > 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
read
> > 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.
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)?
> > 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
()
> > gets it back again.
>
> Or "never", because I'm running RC5 etc. 8(.
Ummmm... Good point! Never mind use of low priorities in UP kernels
for synchronize_kernel()...
Thanx, Paul
In message <OF42269F5F.CDF56B0F-ON88256A27.0083566F@LocalDomain> you write:
> > 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)?
Ah, if you want to inc and dec all the time, yes. But even if the
performance isn't hurt, it's unneccessary, and something else people
have to remember to do.
Simplicity is very nice. And in the case of module unload, gives us
the ability to avoid the distinction between "am I calling into a
module?" and "is this fixed in the kernel?" at runtime. A very good
thing 8)
Rusty.
--
Premature optmztion is rt of all evl. --DK