View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00006951003.1(2008)/Issue 7System Interfacespublic2013-05-12 04:082024-06-11 08:52
Reporterdalias Assigned Toajosey  
PrioritynormalSeverityEditorialTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameRich Felker
Organizationmusl libc
User Reference
SectionXSH 2.9.7 Thread Interactions with Regular File Operations
Page Numberunknown
Line Numberunknown
Interp Status---
Final Accepted Text0000695:0005934
Summary0000695: Missing/lax atomicity requirements for file operations
DescriptionXSH 2.9.7 guarantees atomicity of most operations on file descriptors, but only when they refer to regular files. I suspect the main situation in which it was desired to leave atomicity unspecified was for actual input and output on non-regular files. However, this leaves ambiguous several potentially-important cases such as:

- Atomicity of ftruncate on shared memory objects.
- Atomicity of dup2 and fcntl F_DUPFD[_CLOEXEC].
- Atomicity of F_SETOWN on sockets.
- Atomicity of ownership/permissions changes on non-regular files.
Desired ActionProvide a reasonable degree of atomicity requirements for file operations consistent with present real-world implementations, preferably enumerating the non-atomic cases rather than the atomic ones.

Document that, even in the case where file operations are not atomic, concurrent access does not result in undefined behavior, but may result in data interleaving (and possibly data loss if it's deemed important to leave that possibility open as well).
Tagsissue8

Activities

geoffclare

2022-08-18 15:49

manager   bugnote:0005934

On D2.1 page 509 line 18074 section 2.9.7, change:
Thread Interactions with Regular File Operations

All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on regular files or symbolic links:

[function list]

If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them. The requirement on the close( ) function shall also apply whenever a file descriptor is successfully closed, however caused (for example, as a consequence of calling close( ), calling dup2( ), or of process termination).
to:
Thread Interactions with File Operations

All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on files in the file hierarchy:

chmod( )
chown( )
creat( )
fchmod( )
fchmodat( )
fchown( )
fchownat( )
fstat( )
fstatat( )
ftruncate( )
futimens( )
lchown( )
link( )
linkat( )
lstat( )
open( )
openat( )
readlink( )
readlinkat( )
rename( )
renameat( )
stat( )
symlink( )
symlinkat( )
truncate( )
unlink( )
unlinkat( )
utimensat( )
utimes( )
[Note to the editor: arrange the above list into 5 columns]

If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them.

Except where specified otherwise, all of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on file descriptors that are open, or being opened, to files in the file hierarchy:

close( )
dup2( )
dup3( )
fcntl( )
fstat( )
fstatat( )
ftruncate( )
futimens( )
lseek( )
open( )
openat( )
pread( )
read( )
readv( )
pwrite( )
write( )
writev( )
[Note to the editor: arrange the above list into 5 columns]

If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them. The requirement on the close( ) function shall also apply whenever a file descriptor is successfully closed, however caused (for example, as a consequence of calling close( ), calling dup2( ), or of process termination).

On D2.1 page 881 line 27641 section fcntl(), change:
set the process ID or process group ID specified to receive SIGURG signals
to:
atomically set the process ID or process group ID specified to receive SIGURG signals

After D2.1 page 1885 line 61391 section shm_open(), add a new paragraph:
The following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on shared memory objects:

close(), ftruncate(), mmap(), shm_open(), shm_unlink()

If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them. The requirement on the close( ) function shall also apply whenever a file descriptor is successfully closed, however caused (for example, as a consequence of calling close( ), calling dup2( ), or of process termination).

Issue History

Date Modified Username Field Change
2013-05-12 04:08 dalias New Issue
2013-05-12 04:08 dalias Status New => Under Review
2013-05-12 04:08 dalias Assigned To => ajosey
2013-05-12 04:08 dalias Name => Rich Felker
2013-05-12 04:08 dalias Organization => musl libc
2013-05-12 04:08 dalias Section => XSH 2.9.7 Thread Interactions with Regular File Operations
2013-05-12 04:08 dalias Page Number => unknown
2013-05-12 04:08 dalias Line Number => unknown
2022-08-18 15:49 geoffclare Note Added: 0005934
2022-08-18 15:50 geoffclare Interp Status => ---
2022-08-18 15:50 geoffclare Final Accepted Text => 0000695:0005934
2022-08-18 15:50 geoffclare Status Under Review => Resolved
2022-08-18 15:50 geoffclare Resolution Open => Accepted As Marked
2022-08-18 15:50 geoffclare Tag Attached: issue8
2022-10-21 09:17 geoffclare Status Resolved => Applied
2024-06-11 08:52 agadmin Status Applied => Closed