Andrea Arcangeli wrote:
>
> On Fri, 29 May 1998, Pavel Machek wrote:
>
> >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 I
> looked only its i386 implementation)!
test_and_set is *by* *definition* an atomic operation. However, some
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.
>
> I used test_and_set_bit() in lp to avoid races for SMP in lp_open() (not a
> very critical part of the kernel though, since nobody noticed the race
> also before I put test_and_set_bit() there; probably because /dev/lp0
> usually is opened only from the printer spooler...).
>
> At first I can see test_and_set_bit() very more helpful if
> implemented atomic.
Correct. Otherwise it makes no sense at all to define a function for it!
:-)
>
> As second since it' s declared _not_ atomic in Linux, why i386 implement
> it atomic?
Actually, since there is no need to implement it as atomic in non-SMP
capable architectures, you get the comments such as those in the 68k
architecture (quoting):
/*
* Atomic operations that C can't guarantee us. Useful for
* resource counting etc..
*/
/*
* We do not have SMP m68k systems, so we don't have to deal with that.
*/
(end quote) The comment is correct. :-)
>
> extern __inline__ int test_and_set_bit(int nr, volatile void * addr)
> {
> int oldbit;
>
> __asm__ __volatile__( LOCK_PREFIX
> ^^^^^^^^^^^ why to lock in SMP if it' s not atomic?
> "btsl %2,%1\n\tsbbl %0,%0"
> :"=r" (oldbit),"=m" (ADDR)
> :"ir" (nr));
> return oldbit;
> }
>
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.
> 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.
>
> Andrea[s] Arcangeli
>
> PS. I explicit mentioned the use of test_and_set_bit() to fix not atomic
> operation in lp_open() as first point in the patch comments I sent to
> Linus with the patch itself.
I wouldn't worry about it. Your usage of test_and_set_bit() is correct.
:-)
Regards,
------------------------
André Balsa
andrebalsa@altern.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu