MISRA C:2023 Dir 4.13

Functions which are designed to provide operations on a resource should be called in an appropriate sequence

Since R2024a

Description

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

Directive Definition

Functions which are designed to provide operations on a resource should be called in an appropriate sequence.

Rationale

You typically use functions operating on a resource in the following way:

You allocate the resource.
For example, you open a file or critical section.
You use the resource.
For example, you read from the file or perform operations in the critical section.
You deallocate the resource.
For example, you close the file or critical section.

For your functions to operate as you expect, perform the steps in sequence. For instance, if you call a resource allocation function on a certain execution path, you must call a deallocation function on that path.

Polyspace Implementation

Polyspace Bug Finder™ detects a violation of this rule if you specify multitasking options and your code contains one of these defects:

Missing lock: A task calls an unlock function before calling the corresponding lock function.
Missing unlock: A task calls a lock function but ends without a call to the corresponding unlock function.
Double lock: A task calls a lock function twice without an intermediate call to an unlock function.
Double unlock: A task calls an unlock function twice without an intermediate call to a lock function.

For more information on the multitasking options, see Multitasking.

Extend Checker

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

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

expand all

Multitasking: Lock Function That Is Missing Unlock Function

        
typedef signed int int32_t;
typedef signed short int16_t;

typedef struct tag_mutex_t {
    int32_t value;
} mutex_t;


extern mutex_t mutex_lock   ( void );
extern void  mutex_unlock (  mutex_t m );

extern int16_t x;
void func(void);

void task1(void) {
     func();
}

void task2(void) {
     func();
}

void func ( void ) {
    mutex_t m = mutex_lock ( );  /* Non-compliant */

    if ( x > 0 )  {
        mutex_unlock ( m );
    }  else  {
        /* Mutex not unlocked on this path */
    }
}

In this example, the rule is violated when:

You specify that the functions mutex_lock and mutex_unlock are paired.
mutex_lock begins a critical section and mutex_unlock ends it.
The function mutex_lock is called. However, if x <= 0, the function mutex_unlock is not called.

To enable detection of this rule violation, you must specify these analysis options.

Option	Specification
Configure multitasking manually
Entry points	`task1` `task2`
Critical section details	Starting routine	Ending routine
Critical section details	`mutex_lock`	`mutex_unlock`

For more information on the options, see:

Check Information

Group: Code design

Category: Advisory

AGC Category: Advisory

Version History

Introduced in R2024a