Re: test_and_set_bit() not atomic forever? [cli/sti in char/vt.c [patch]]
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Sun, 31 May 1998 14:25:39 +1000
Rafael R. Reilova writes:
> Hello,
>
> On Sun, 31 May 1998, Richard Gooch wrote:
>
> > Andrew Derrick Balsa writes:
>
> ...
> > > > >Don't think so. Well, it is safe on i386, but on other architectures,
> > > > >test_and_set_bit is not guaranteed to be atomic. [And I'm afraid that
> > > > Arggh I thought that test_and_set_bit() was atomic on all ports (since =
> > >
> > > test_and_set is *by* *definition* an atomic operation. However, some
>
> Does everyone agree on this? If so I'm going back to the original patch,
> test_and_set feels so much simpler and to the point than these
> atomic_dec_and_test, atomic_..., etc
>
> > > processors don't have an opcode that implements atomic test_and_set. On
> > > these processors, we either use another atomic instruction to build a
> > > function that implements atomic test_and_set, or, if the architecture is
> > > not SMP capable, just forget about the atomicity requirement.
> >
> > Hold on: even if the machine has a single CPU, you still need to
> > guarantee atomicity because of interrupt handlers. On a single CPU
> > machine you could do this by disabling interrupts. But you can't
> > just ignore the whole issue because you only have one CPU.
>
> This operation is still atomic on the x86. Either the instruction
> executes before the interrupt of afterwards. Of course, it must come down
> to *one* machine instruction[1]. If it doesn't, then cli/sti or equiv.
> would be needed.
But on a CPU which doesn't have an atomic test and set instruction,
you need to disable interrupts. I wasn't talking about the x86 because
the "atomic" operations work properly there.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu