[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]]

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.



[1] There may be some exceptions, the repeat and string instructions come
to mind, also misaligned memory refereces. Anyways, these don't apply
here, just for the nitpickers ;-)

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.066 / U:6.072 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site