> -----Original Message-----
> From: yyyyyyy@xxxxxxxxxx [mailto:yyyyyyy@xxxxxxxxxx]
> Sent: Sunday, November 27, 2005 6:36 PM
> To: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
> Subject: Defect in XSH mmap()
>
> Defect report from : Ulrich Drepper , Red Hat, Inc.
>
> (Please direct followup comments direct to
> yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
>
> @ page 786 line 25802 section mmap() comment {ud-shared-sync}
>
> Problem:
>
> Edition of Specification (Year): 2004
>
> Defect code : 3. Clarification required
>
> [I attach this report to mmap and this might be where an
> explanation can be placed, but it applies to the pthread sync
> primitives.]
>
>
> Consider a process which create a file, mmap()s it with
> MAP_SHARED, and in the shared memory region creates a
> pthread_mutex_t object with the pshared attribute set (i.e.,
> pthread_mutexattr_setpshared used).
>
> This is supposed to work and other processes can just map the
> file and use the shared mutex.
>
> But what happens if all processes, which have the shared
> memory region mapped, either terminate or unmap the memory.
> If this happened, will another process then be able to open
> the file and use the shared mutex right away without initialization?
[...]
I suggest adding a separate function to cover this case:
pthread_mutex_reinit(pthread_mutex_t *mutex) /* or perhaps
"pthread_mutex_announce(pthread_mutex_t *mutex)" */
Applications would be required to call this for each mutex contained in
a file that they just had mapped, if it were possible that the file had
been completely unmapped before.
This might provide the necessary "hint" to the implementation to make
this situation efficient, without placing undue burdens on the
application.
Regards,
Konrad Schwarz
|