CWE Rule 764

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

This issue occurs when:

In multitasking code, a lock function begins a critical section of code and an unlock function ends it. When a task task1 calls a lock function lock, other tasks calling lock must wait until task calls the corresponding unlock function.

To find this defect, specify your lock and unlock functions using one of these methods:

A call to a lock function begins a critical section so that other tasks have to wait to enter the same critical section. If the same lock function is called again within the critical section, the task blocks itself.

The fix depends on the root cause of the defect. A double lock defect often indicates a coding error. Perhaps you omitted the call to an unlock function to end a previous critical section and started the next critical section. Perhaps you wanted to use a different lock function for the second critical section.

Identify each critical section of code, that is, the section that you want to be executed as an atomic block. Call a lock function at the beginning of the section. Within the critical section, make sure that you do not call the lock function again. At the end of the section, call the unlock function that corresponds to the lock function.

See examples of fixes below. To avoid the issue, you can follow the practice of calling the lock and unlock functions in the same module at the same level of abstraction. For instance, in this example, func calls the lock and unlock function at the same level but func2 does not.

void func() {
  my_lock();
  {
    ...
  }
  my_unlock();
}

void func2() {
  {
   my_lock();
   ...
  }
  my_unlock();
}

If you do not want to fix the issue, add comments to your result or code to avoid another review. See:

You might be using locking functions that are not supported by Polyspace. Extend this checker by mapping your locking functions to its known POSIX^® equivalent. See Extend Concurrency Defect Checkers to Unsupported Multithreading Environments.

int global_var;

void lock(void);
void unlock(void);

void task1(void)
{
    lock();
    global_var += 1;
    lock();  //Noncompliant
    global_var += 1;
    unlock();
}

void task2(void)
{
    lock(); 
    global_var += 1;
    unlock();
}

In this example, to emulate multitasking behavior, you must specify the following options:

Option	Value
Configure multitasking manually
Tasks (-entry-points)	task1 task2
Critical section details (-critical-section-begin -critical-section-end)	Starting routine	Ending routine
	lock	unlock

On the command-line, you can use the following:

 polyspace-bug-finder
   -entry-points task1,task2
   -critical-section-begin lock:cs1
   -critical-section-end unlock:cs1

task1 enters a critical section through the call lock();. task1 calls lock again before it leaves the critical section through the call unlock();.

If you want the first global_var+=1; to be outside the critical section, one possible correction is to remove the first call to lock. However, if other tasks are using global_var, this code can produce a Data race error.

int global_var;

void lock(void);
void unlock(void);

void task1(void)
{
    global_var += 1;
    lock(); 
    global_var += 1;
    unlock();
}

void task2(void)
{
    lock(); 
    global_var += 1;
    unlock();
}

If you want the first global_var+=1; to be inside the critical section, one possible correction is to remove the second call to lock.

int global_var;

void lock(void);
void unlock(void);

void task1(void)
{
    lock();
    global_var += 1;
    global_var += 1;
    unlock();
}

void task2(void)
{
    lock(); 
    global_var += 1;
    unlock();
}

If you want the second global_var+=1; to be inside a critical section, another possible correction is to add another call to unlock.

int global_var;

void lock(void);
void unlock(void);

void task1(void)
{
    lock();
    global_var += 1;
    unlock();
    lock();
    global_var += 1;
    unlock();
}

void task2(void)
{
    lock(); 
    global_var += 1;
    unlock();
}

int global_var;

void lock(void);
void unlock(void);

void performOperation(void) {
  lock(); //Noncompliant
  global_var++;
}

void task1(void)
{
    lock();
    global_var += 1;
    performOperation();
    unlock();
}

void task2(void)
{
    lock(); 
    global_var += 1;
    unlock();
}

In this example, to emulate multitasking behavior, you must specify the following options:

Option	Specification
Configure multitasking manually
Tasks (-entry-points)	task1 task2
Critical section details (-critical-section-begin -critical-section-end)	Starting routine	Ending routine
	lock	unlock

On the command-line, you can use the following:

 polyspace-bug-finder
   -entry-points task1,task2
   -critical-section-begin lock:cs1
   -critical-section-end unlock:cs1

task1 enters a critical section through the call lock();. task1 calls the function performOperation. In performOperation, lock is called again even though task1 has not left the critical section through the call unlock();.

In the result details for the defect, you see the sequence of instructions leading to the defect. For instance, you see that following the first entry into the critical section, the execution path:

You can click each event to navigate to the corresponding line in the source code.

One possible correction is to remove the call to lock in task1.

int global_var;

void lock(void);
void unlock(void);

void performOperation(void) {
  global_var++;
}

void task1(void)
{
    lock();
    global_var += 1;
    performOperation();
    unlock();
}

void task2(void)
{
    lock(); 
    global_var += 1;
    unlock();
}