Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001404 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2020-09-24 00:44 2020-09-24 00:44
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Rich Felker
Organization musl libc
User Reference
Section pthread_mutex_destroy
Page Number (page or range of pages)
Line Number (Line or range of lines)
Interp Status ---
Final Accepted Text
Summary 0001404: Is there a requirement to destroy mutex before object lifetime ends?
Description The specification of pthread_mutex_destroy establishes conditions under which behavior of call to pthread_mutex_destroy is undefined, but does not cover whether there are conditions under which failure to call it is undefined. If the lifetime of a pthread_mutex_t object with automatic or allocated storage duration (or mmap/MAP_ANON) ends (end of execution of block, call to free, munmap, etc.) without a call to pthread_mutex_destroy, is or should the behavior be undefined?

I tend to believe it should be undefined, because the intent of having init/destroy functions seems to be to allow implementation flexibility that would include things like keeping a linked list of all existant objects for error-checking (necessary for diagnostic of double init, etc.), using allocation in pthread_mutex_init (in which failure to call pthread_mutex_destroy is a memory leak, which although not inherently fatal, is bad), and so on.
Desired Action Possibly add text to description:

"If the lifetime of an initialized pthread_mutex_t object ends without a call to pthread_mutex_destroy, the behavior is undefined."

It's likely that this proposal needs further discussion, particularly for the case of process-shared objects living in MAP_SHARED (and maybe also MAP_ANON) memory where the end of the object lifetime is not well-defined, and where it may be desirable to allow omission of pthread_mutex_destroy because of software that relies on the shared memory ceasing to exist when the last user unmaps it.

If an action is taken on this, similar actions are probably needed for other pthread object types.
Tags No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2020-09-24 00:44 dalias New Issue
2020-09-24 00:44 dalias Name => Rich Felker
2020-09-24 00:44 dalias Organization => musl libc
2020-09-24 00:44 dalias Section => pthread_mutex_destroy
2020-09-24 00:44 dalias Page Number => (page or range of pages)
2020-09-24 00:44 dalias Line Number => (Line or range of lines)


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker