Page History

When accessing a bit-field, a thread may inadvertently access a separate bit-field in adjacent memory. This is because compilers are required to store multiple adjacent bit-fields in one storage unit whenever they fit. Consequently, data races may exist not just on a bit-field accessed by multiple threads but also on other bit-fields sharing the same byte or word.  A similar problem is discussed in CON00-C. Avoid race conditions with multiple threads, but the issue described by this issue rule can be harder to diagnose because it is may not immediately be obvious that the same memory location is being modified by multiple threads.

One approach for preventing data races in concurrent programming is the to use a mutex. When properly observed by all threads, a mutex can provide safe and secure access to a shared object. However, mutexs provide no guarantees with regard to other objects that might be accessed when the mutex is not controlled by the accessing thread. Unfortunately, there is no portable way to determine which adjacent bit-fields may be stored along with the desired bit-field.

...

Adjacent bit-fields may be stored in a single memory location. Consequently, modifying adjacent bit-fields in different threads is undefined behavior, as shown in this noncompliant code example:

struct multi_threaded_flags {
  unsigned int flag1 : 2;
  unsigned int flag2 : 2;
};

struct multi_threaded_flags flags;

int thread1(void *arg) {
  flags.flag1 = 1;
  return 0;
}

int thread2(void *arg) {
  flags.flag2 = 2;
  return 0;
}

The C Standard, subclause 3.14, paragraph 3 [ISO/IEC 9899:2011], states:

...

For example, the following sequence of events can occurinstruction sequence is possible:

Thread 1: register 0 = flags
Thread 1: register 0 &= ~mask(flag1)
Thread 2: register 0 = flags
Thread 2: register 0 &= ~mask(flag2)
Thread 1: register 0 |= 1 << shift(flag1)
Thread 1: flags = register 0
Thread 2: register 0 |= 2 << shift(flag2)
Thread 2: flags = register 0

...

This compliant solution protects all accesses of the flags with a mutex, thereby preventing any data races.:

#include <threads.h>
 
struct multi_threaded_flags {
  unsigned int flag1 : 2;
  unsigned int flag2 : 2;
};

struct mtf_mutex {
  struct multi_threaded_flags s;
  mtx_t mutex;
};

struct mtf_mutex flags;

int thread1(void *arg) {
  if (thrd_success != mtx_lock(&flags.mutex)) {
    /* Handle error */
  }
  flags.s.flag1 = 1;
  if (thrd_success != mtx_unlock(&flags.mutex)) {
    /* Handle error */
  }
  return 0;
}
 
int thread2(void *arg) {
  if (thrd_success != mtx_lock(&flags.mutex)) {
    /* Handle error */
  }
  flags.s.flag2 = 2;
  if (thrd_success != mtx_unlock(&flags.mutex)) {
    /* Handle error */
  }
  return 0;
}

...

In this compliant solution, two threads simultaneously modify two distinct non-bit-field members of a structure:. Because the members occupy different bytes in memory, no concurrency protection is required.

struct multi_threaded_flags {
  unsigned char flag1;
  unsigned char flag2;
};
 
struct multi_threaded_flags flags;
 
int thread1(void *arg) {
  flags.flag1 = 1;
  return 0;
}

int thread2(void *arg) {
  flags.flag2 = 2;
  return 0;
}

...

NOTE 1 Two threads of execution can update and access separate memory locations without interfering with each other.

In Using a compiler that is only compliant with conforms to C99 or earlier, it is possible that flag1 and flag2 are stored in the same word. If both assignments occur on a thread-scheduling interleaving that ends with both stores occurring after one another, it is possible that only one of the flags will be set as intended, and the other flag will contain its previous value, because both members are represented by the same word, which is the smallest unit the processor can work on. Before the changes made to the C Standard for C11, there were no guarantees that these flags could be modified concurrently.

...

Bibliography

...