[lkml]   [1998]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: test_and_set_bit() not atomic forever? [cli/sti in char/vt.c [patch]]
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.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.100 / U:1.508 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site