Question

I’m trying to implement a mutex in C using the atomic assembly instruction “bts” to atomically set a bit and return the original value.
However, when I run the following code, it occasionally deadlocks and often shows race conditions:

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

typedef unsigned char mutex;
#define MUTEX_FREE 0
#define MUTEX_BUSY 1

// adapted from http://www.acm.uiuc.edu/sigops/roll_your_own/i386/atomic.html
mutex testAndSet(mutex *m) {
    int result;
    asm ("bts $0, %1; sbbl %0, %0"
         :"=r" (result)
         :"m" (*m)
         :"memory");
    return (result & 1);
}

void P(mutex *m) {
    // Must use atomic testAndSet to avoid race conditions
    while(testAndSet(m) == MUTEX_BUSY)
        usleep(10);
}

void V(mutex *m) {
    *m = MUTEX_FREE;
}

//////////////
// Test:
//////////////

const int NTHREADS = 100;
const int NINCS = 100;

int counter = 0;
mutex m = MUTEX_FREE;

void criticalSection() {
    int i;
    for(i=0;i<NINCS;i++) {
        P(&m);
        counter++;
        V(&m);
    }
}

int main() {
    int i;
    pthread_t threads[NTHREADS];
    for(i=0; i<NTHREADS; i++) {
        pthread_create(&threads[i], NULL, (void *) &criticalSection, NULL);
    }
    for(i=0; i<NTHREADS; i++) {
        pthread_join(threads[i], NULL);
    }
    printf("got counter=%d, expected=%d\n", counter, NTHREADS*NINCS);
}

The code seems to work if I use the “xchgb” instruction instead of “bts” as follows:

mutex testAndSet(mutex *m) {
    unsigned char result = MUTEX_BUSY;
    asm ("xchgb %1, %0"
            :"=m" (*m), "=r" (result)
            :"1" (result)
            :"memory");
    return result;
}

Where is the race condition in the original code? Shouldn’t the “bts” instruction be atomic, guaranteeing thread safety?

Furthermore, is my modified solution actually correct?

(I’m running OS X 10.8 and compiling with gcc.)

Answer 1

Try using the LOCK prefix to lock the memory bus:

asm ("lock bts $0, %1; ...");

The xchg instruction worked because that always asserts the LOCK# signal regardless of the presence or absence of the LOCK prefix.