View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001120 | 1003.1(2016/18)/Issue7+TC2 | System Interfaces | public | 2017-02-23 02:38 | 2018-08-02 15:40 |
| Reporter | a3f | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Closed | Resolution | Rejected | ||
| 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. | ||||
|
|
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. |
|
|
On the August 2, 2018 conference call, it was noted this would be an extension to the C standard without existing practice. If practice emerges that demonstrates that this concept can be implemented reliably this issue may be reintroduced, but presently we cannot approve this enhancement. The submitter is encouraged to raise this matter with implementers so that this practice can be developed. |
| 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/18)/Issue7+TC2 |
| 2018-08-02 15:40 | geoffclare | Interp Status | => --- |
| 2018-08-02 15:40 | geoffclare | Note Added: 0004068 | |
| 2018-08-02 15:40 | geoffclare | Status | Under Review => Closed |
| 2018-08-02 15:40 | geoffclare | Resolution | Open => Rejected |
