MISRA C:2012 Rule 22.15

Thread synchronization objects and thread-specific storage pointers shall not be destroyed until after all threads accessing them have terminated

Since R2024b

Description

This checker is deactivated in a default Polyspace^® as You Code™ analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace as You Code).

Rule Definition

Thread synchronization objects and thread-specific storage pointers shall not be destroyed until after all threads accessing them have terminated¹ .

This rule comes from MISRA C™: 2012 Amendment 4.

Rationale

Destroying mutex objects or thread-specific storage objects before the termination of all threads accessing these resources can lead to undefined behavior. For example:

• The function mtx_destroy() releases the resources used by a mutex object. In this code, the thread bar() locks the mutex object myMutex and the thread foo() destroys it. The mutex object myMutex can be locked when it is destroyed by foo().

  mtx_t myMutex;
  //...
  void foo() { // Thread foo
  	//...
  	mtx_destroy(myMutex); // Can be undefined behavior
  }
  
  
  void bar() { // Thread bar
  	mtx_lock(myMutex);
  	//...
  }

  Destroying a locked mutex results in undefined behavior.

• The function tss_delete() releases all resources used by a thread-specific storage object. In this code, the thread foo() accesses the thread specific storage object myStorage. When the thread bar() releases this storage, myStorage might still be used by the thread foo(), resulting in undefined behavior.

  tss_t myStorage;
  //...
  void foo() { // Thread foo
  	tss_set(myStorage, malloc(4));
      //...
  }
  
  
  void bar() { // Thread bar
  	//..
  	tss_delete(myStorage);      // Can be undefined behavior
  }

• The function cnd_destroy() destroys condition variables. In this code, the threads foo() and bar() use the condition variable myCV. When the thread bar() destroys myCV, the condition variable might still be used by the thread foo(), resulting in undefined behavior.

  mtx_t myMutex;
  cnd_t myCV;
  //...
  void foo() { // Thread foo
  	//...
  	cnd_wait(&myCV, &myMutex);
  	//...
  }
  
  
  void bar() { // Thread bar
  	//..
      cnd_wait(&myCV, &myMutex);
      //..
  	cnd_destroy(&cond_var);      // Can be undefined behavior
  }

To avoid such instances of undefined behavior, check that all threads have been terminated before destroying shared resources. Alternatively, avoid destroying shared resources at all.

Polyspace Implementation

Polyspace reports a violation of this rule when:

• A task destroys a mutex object after it is locked and before it is unlocked.

• A task deletes a thread specific storage object before all thread using it are joined.

• A task deletes thread specific storage object after it is registered using tss_create() but before any threads using the object are started.

The locking and destruction can happen in the same task or different tasks. A task is a function that you specify as an entry point using the option Tasks (-entry-points).

Troubleshooting

If you expect a rule violation but do not see it, refer to Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

Destruction of Locked Mutex

In this example, the mutex object mutexB is locked by the thread worker1(). This mutex object is then destroyed by worker2(). The thread worker1() might still be blocked by mutexB when worker2() destroys the mutex object, which results in undefined behavior. Polyspace reports a violation.

#include <stdio.h>
#include <threads.h>
void doSomeWork(void);
// Mutex declaration
mtx_t mutexA, mutexB;

// Worker function 1
int worker1(void *arg) {
	printf("Worker 1 is trying to lock the mutex.\n");
	mtx_lock(&mutexA);
	mtx_lock(&mutexB);
	printf("Worker 1 has locked the mutex.\n");
	// Work
	doSomeWork();
	printf("Worker 1 is unlocking the mutex.\n");
	mtx_unlock(&mutexA);
	return 0;
}

// Worker function 2
int worker2(void *arg) {
	printf("Worker 2 is trying to lock the mutex.\n");
	mtx_lock(&mutexA);
	printf("Worker 2 has locked the mutex.\n");
	// Work
	doSomeWork() ;
	printf("Worker 2 is unlocking the mutex.\n");
	mtx_unlock(&mutexA);
	// destroy mutexB
	mtx_destroy(&mutexB); /* Noncompliant */
	return 0;
}

// Main function
int main() {
	thrd_t t1, t2;

	// Initialize mutex
	mtx_init(&mutexA, mtx_plain);
	mtx_init(&mutexB, mtx_plain);

	// Create worker threads
	if(thrd_create(&t1, worker1, NULL) != thrd_success) {
		printf("Failed to create thread 1.\n");
		return 1;
	}
	if(thrd_create(&t2, worker2, NULL) != thrd_success) {
		printf("Failed to create thread 2.\n");
		return 1;
	}

	// Wait for threads to finish
	thrd_join(t1, NULL);
	thrd_join(t2, NULL);



	return 0;
}

For this example, specify worker1 and worker2 as entry-point functions. In the Polyspace user interface, specify these options:

Option	Value
Configure multitasking manually	On
Tasks (-entry-points)	worker1 worker2

Alternatively, at the command line, use this command:

polyspace-bug-finder -entry-points worker1,worker2

Thread Specific Storage Deleted Before Thread Terminates

In this example, the function t_func uses the thread specific storage key. This thread specific storage is deleted before the thread running t_func terminates. Polyspace reports a violation on the deletion of the thread specific storage.

#include <threads.h>

#define NULL 0

tss_t      key;
thrd_t     id;

void t_func(void) {
	void *data = tss_get(key);
	tss_set(key, data);
}

void main(void)
{
	tss_create(&key, NULL);
	thrd_create(&id, t_func, NULL);
	tss_delete(key);             /*Noncompliant */
}

Check Information

Group: Resources

Category: Required

AGC Category: Required

PQL Name: std.misra_c_2012.R22_15

Version History

Introduced in R2024b

R2026a: Violation reported if thread specific storage is deleted while before thread terminates

Polyspace reports a violation if a thread specific storage object is deleted but the threads using the object are not joined or still not started.