Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001120 [1003.1(2016)/Issue7+TC2] System Interfaces Editorial Enhancement Request 2017-02-23 02:38 2017-02-27 09:49
Reporter a3f View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Ahmad Fatoum
Organization
User Reference
Section 2.4.3 Signal Actions
Page Number 493
Line Number 16839-16842
Interp Status ---
Final Accepted Text
Summary 0001120: Permit access to static storage objects from signal handlers if synchronization is guaranteed by use of the signal mask
Description While the recent C standard (ISO 9899:2011) additionally allows for using the newly introduced lock-free atomic types inside signal handlers, access to static storage duration objects of types other then those provided as lock-free atomics remains undefined.

Notably following access pattern, often employed in interrupt handlers, remains undefined: Access to objects that are only referenced inside an interrupt handler or while said interrupt is masked, are "async-interrupt-safe".

I believe that with the concurrency model introduced in C11, these kind of accesses could be defined. This would allow for use of the aforementioned interrupt access pattern in conjunction with UNIX signals, which after all, were modeled after interrupts.
Desired Action Amending the section with something along the lines of:

"Inside signal handlers, access to objects with static storage duration and of arbitrary type is permitted if and only if all accesses to the object, inside or outside the signal handler, occur while said signal handler is blocked from execution."

This would be coupled with making modification of the signal mask imply a barrier.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0003573)
shware_systems (reporter)
2017-02-25 20:20

This is nominally on my to do list, but there are significant issues C11 leaves under-specified. I don't believe there is a current implementation of the concept that can be considered portable either.

While C11 does add thread local or static lock-free variables >may< be referred to in the signal() description, I see this as necessarily platform-dependent; no types with an _Atomic qualifier are required to be lock-free. Which ones are lock-free on a given platform is reported via the ATOMIC_*_LOCK_FREE macros, and these can all be set to a 0 value, indicating "never lock-free". With CPUs that do not support read-modify-write operations, which I believe is most RISC architectures, this will be the usual case. Compilers for these platforms are more likely to #define __STDC_NO_ATOMICS__ instead, and block any attempt to #undef the symbol.

Some CISC CPUs, like the x86 series, use LOCK prefixes on r-m-w operations to force atomicity. On those systems the atomic_is_lock_free() interface can, and should imo, always return 1 for static variables. Thread local storage blocked from any type of sharing might return 2, and is the class of storage I'd limit an extension like this to. The <threads.h> and <pthreads.h> headers need additional interfaces imo to make this robust, however. Unspecified compiler options determine which code gets LOCK prefixes, not an objects location in RAM, so a restriction like this I see as needed to make prefixes unnecessary.

The only type required to behave as atomically accessible in handlers on all platforms is still sig_atomic_t, and even when volatile qualified the atomicity guarantee is for a single read or single write. An overwrite of the location by a separate CPU sharing the memory or DMA peripheral can occur during any modify operation in between made by a handler, whether the signal is blocked or not. The C logical model, still, more assumes a single CPU has access to RAM and I/O is handled synchronously via port accesses by a single threaded process, so doesn't really address these common possibilities.

The net effect I see is strictly conforming handler code will still be limited to variables of sig_atomic_t type in Issue 8. To what extent the <stdatomics.h> header will be characterized as an option, extended as above, subset-ted, or can be provided via emulation using mutexes and similar (despite the performance hit), is still to be determined. It probably won't be until Issue 10 before whatever is approved can be made part of the base, if c2x leaves it as an optional header. C11 makes provision for emulation by allowing a mutex or other lock to be attached to an _Atomic declaration, in 7.17.6p3. A plausible subset that should be portable is requiring init, load, store, and fences be supported for just int and unsigned int, but exclude the fetch, xchg, and flag operations, as this is basically the level of support sig_atomic_t needs anyways.

Requiring all elements of any arrays or structs to be _Atomic qualified I think will be necessary also for this extension, possibly volatile qualified also. For arrays this is an extension to C11, and the standard is ambiguous, to me, about the effects of _Atomic as a type qualifier of structs and unions, or type specifier with a struct typedef type-name as argument. Further requirements related to process shared memory and locking also need specifying.

- Issue History
Date Modified Username Field Change
2017-02-23 02:38 a3f New Issue
2017-02-23 02:38 a3f Status New => Under Review
2017-02-23 02:38 a3f Assigned To => ajosey
2017-02-23 02:38 a3f Name => Ahmad Fatoum
2017-02-23 02:38 a3f Section => 2.4.3 Signal Actions
2017-02-23 02:38 a3f Page Number => 493
2017-02-23 02:38 a3f Line Number => 16839-16842
2017-02-25 20:20 shware_systems Note Added: 0003573
2017-02-27 09:49 geoffclare Project 1003.1(2004)/Issue 6 => 1003.1(2016)/Issue7+TC2


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