Page History

When multiple threads must access or make modifications to a common variable, they may also inadvertently access other variables in adjacent in memory. This is This is an artifact of variables being stored compactly, with one byte possibly holding multiple variables, and is a common optimization on word-addressed machines. Bit-fields are especially prone to this behavior because compliers compilers are allowed to store multiple bit-fields in one addressable byte or word. This implies that Consequently, race conditions may exist not just on a variable accessed by multiple threads , but also on other variables sharing the same byte or word address.

A common tool for preventing race conditions in concurrent programming is the mutex. When properly observed by all threads, a mutex can provide safe and secure access to a common variable; however, it guarantees nothing with regards regard to other variables that might be accessed when a common variable is accessed.

...

A better approach is to embed a concurrently - accessed variable inside a union, along with a long variable, or at least some padding to ensure that the concurrent variable is the only element to be accessed at that address. This technique would effectively guarantee that no other variables are accessed or modified when the concurrent variable is accessed or modified.

Noncompliant Code Example (Bit

...

-field)

In this noncompliant code example, two executing threads simultaneously access two separate members of a global struct.

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

struct multi_threaded_flags flags;

void thread1(void) {
  flags.flag1 = 1;
}

void thread2(void) {
  flags.flag2 = 2;
}

Although this code appears to be harmless, it is likely that flag1 and flag2 are stored in the same byte. 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 equal its previous value. This is , because both bit-fields are represented by the same byte, which is the smallest unit the processor can work on.

...

Even though each thread is modifying a separate bit-field, they are both modifying the same location in memory. This is the same problem discussed is discussed in recommendation CON00-C. Avoid race conditions with multiple threads, but it is harder to diagnose because it is not immediately obvious at first glance that the same memory location is being modified.

Compliant Solution (Bit

...

-field)

This compliant solution protects all accesses of the flags with a mutex, thereby preventing any thread-scheduling interleaving from occurring. In addition, the flags are declared volatile to ensure that the compiler will not attempt to move operations on them outside the mutex. Finally, the flags are embedded in a union alongside a long, and a static assertion guarantees that the flags do not occupy more space than the long. This prevents technique prevents any data not checked by the mutex from being accessed or modified with the bit-fields.

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

union mtf_protect {
  struct multi_threaded_flags s;
  long padding;
};

static_assert(sizeof(long) >= sizeof(struct multi_threaded_flags));

struct mtf_mutex {
  union mtf_protect u;
  mtx_t mutex;
};

struct mtf_mutex flags;

void thread1(void) {
  int result;
  if ((result = mtx_lock(&flags.mutex)) == thrd_error) {
    /* Handle error */
  }
  flags.u.s.flag1 = 1;
  if ((result = mtx_unlock(&flags.mutex)) == thrd_error) {
    /* Handle error */
  }
}

void thread2(void) {
  int result;
  if ((result = mtx_lock(&flags.mutex)) == thrd_error) {
    /* Handle error */
  }
  flags.u.s.flag2 = 2;
  if ((result = mtx_unlock(&flags.mutex)) == thrd_error) {
    /* Handle error */
  }
}

Static assertions are discussed in detail in recommendation DCL03-C. Use a static assertion to test the value of a constant expression.

...

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

ISO/IEC 9899:1999 Section 2011 Section 6.7.2.1, "Structure and union specifiers"

...

...