Messages in this thread | | | Date | Sat, 30 May 1998 21:20:53 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: test_and_set_bit() not atomic forever? [cli/sti in char/vt.c [patch]] |
| |
On Sat, 30 May 1998, Andrew Derrick Balsa wrote:
>Since the bit test and set instruction in the i386 architecture is not >atomic, we use the LOCK prefix to make it so. Like that we get a >test_and_set_bit() which *is* atomic, hence SMP-safe.
What I want to say is that if _only_one_ Linux port will not implement test_and_set_bit() in an atomic way (as i386 does) this will break all other ports atomic implementation (so i386 could implement test_and_set not atomic too).
Pavel said:
>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
and this doesn' t feel like "on some architecture test_and_set_bit() is still buggy so it' s better not use it for __now__ but God ;-) is just working to fix it.".
>> So I' d like to know if test_and_set_bit() will forever remain declared >> not atomic for all ports to know if I need to refix lp_open()... > >You shouldn't have to refix anything. If other SMP-capable architectures >get implemented under Linux, whoever develops those will implement >(correctly) test_and_set as an atomic operation.
Ok, I agree 100%. Also the bip (beep) device could use test_and_set_bit() as lp_open() does (maybe other port maintainers will be more forced to fix test_and_set_bit() if the bip device will break their machines every hour ;-).
Andrea[s] Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |