lkml.org 
[lkml]   [1998]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

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