On Monday 10 September 2007 15:51, Arjan van de Ven wrote:
> On Mon, 10 Sep 2007 11:56:29 +0100
> Denys Vlasenko <[EMAIL PROTECTED]> wrote:
>
> >
> > Well, if you insist on having it again:
> >
> > Waiting for atomic value to be zero:
> >
> > while (atomic_read(&x))
> > continue;
> >
>
> and this I would say is buggy code all the way.
>
> Not from a pure C level semantics, but from a "busy waiting is buggy"
> semantics level and a "I'm inventing my own locking" semantics level.
After inspecting arch/*, I cannot agree with you.
Otherwise almost all major architectures use
"conceptually buggy busy-waiting":
arch/alpha
arch/i386
arch/ia64
arch/m32r
arch/mips
arch/parisc
arch/powerpc
arch/sh
arch/sparc64
arch/um
arch/x86_64
All of the above contain busy-waiting on atomic_read.
Including these loops without barriers:
arch/mips/kernel/smtc.c
while (atomic_read(&idle_hook_initialized) < 1000)
;
arch/mips/sgi-ip27/ip27-nmi.c
while (atomic_read(&nmied_cpus) != num_online_cpus());
[Well maybe num_online_cpus() is a barrier, I didn't check]
arch/sh/kernel/smp.c
if (wait)
while (atomic_read(&smp_fn_call.finished) != (nr_cpus - 1));
Bugs?
--
vda
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
