A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1120 ====================================================================== Reported By: a3f Assigned To: ajosey ====================================================================== Project: 1003.1(2004)/Issue 6 Issue ID: 1120 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal 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: ====================================================================== Date Submitted: 2017-02-23 02:38 UTC Last Modified: 2017-02-25 20:20 UTC ====================================================================== Summary: Permit access to static storage objects from signal handlers if synchronization is guaranteed by use of the signal mask ======================================================================
---------------------------------------------------------------------- (0003573) shware_systems (reporter) - 2017-02-25 20:20 http://austingroupbugs.net/view.php?id=1120#c3573 ---------------------------------------------------------------------- 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 ======================================================================
