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]]
    Hi Andrea,

    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

    \
     
     \ /
      Last update: 2005-03-22 13:42    [W:0.030 / U:0.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site