[1003.1(2013)/Issue7+TC1 0000864]: Insufficient specification of storage requirements for synchronization objects

[Austin Group Bug Tracker]

A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=864
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 864
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Rich Felker
Organization: musl libc
User Reference:
Section: unknown
Page Number: unknown
Line Number: unknown
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-08 23:03 UTC
Last Modified: 2014-09-16 18:42 UTC
======================================================================
Summary: Insufficient specification of storage requirements
for synchronization objects
======================================================================

----------------------------------------------------------------------
(0002389) martinr (reporter) - 2014-09-16 18:42
http://austingroupbugs.net/view.php?id=864#c2389
----------------------------------------------------------------------
Solaris unmes kernel mutex when pthred_mutex_t is initialized with
PTHREAD_PROCESS_SHARED attribute. Also mutex becomes a
shared-between-processes
when the mutex is initialized with PTHREAD_MUTEX_ROBUST attribute. In both
cases there exist a linked list of pointers referring to pthread_mutex_t
structures in the address space of the process. Let's call this type B.

On the other hand if we don't have neither PTHREAD_PROCESS_SHARED or
PTHREAD_MUTEX_ROBUST mutex the is no reference to pthread_mutex_t in the
address space and all the locking related functionality happens in the
user
space. Let's call it type A.

All the pthread library mutex related locking features on Solaris derive
from this.

Here you can find answers for questions found in 'Desired Action'.
Generally I
didn't find a word about any of the questions in the documentation which
means
the result is undefined.

1. It will work.

2. Generally you can't deallocate without destroy type B. For type A you
can do it in case there is no risk of dead lock (multiple cases).

3.1 Should work.
3.2 Should work.
3.3 Generally it will not work.

4. It will work just for type A.

Issue History
Date Modified Username Field Change
======================================================================
2014-08-08 23:03 dalias New Issue
2014-08-08 23:03 dalias Name => Rich Felker
2014-08-08 23:03 dalias Organization => musl libc
2014-08-08 23:03 dalias Section => unknown
2014-08-08 23:03 dalias Page Number => unknown
2014-08-08 23:03 dalias Line Number => unknown
2014-09-16 18:42 martinr Note Added: 0002389
======================================================================