[cpp-threads] Slightly revised memory model proposal (D2300)

Alexander Terekhov alexander.terekhov at gmail.com
Tue Jun 5 21:06:21 BST 2007


On 6/5/07, Lawrence Crowl <Lawrence at crowl.org> wrote:
> Is there any problem with the standard modeling the interrupt
> as simply another thread?

POSIX has a mechanism for that[1]. But interrupts are no threads. An
implementation can make volatile sig_atomic_t "interrupt safe" by
simply disabling interrupts around accesses to volatile sig_atomic_t's
in the accessing thread. No barriers and/or thread atomicity needed.

[1] http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

Multi-threaded programs can use an alternate event notification
mechanism. When a notification is processed, and the sigev_notify
member of the sigevent structure has the value SIGEV_THREAD, the
function sigev_notify_function is called with parameter sigev_value.

The function shall be executed in an environment as if it were the
start_routine for a newly created thread with thread attributes
specified by sigev_notify_attributes. If sigev_notify_attributes is
NULL, the behavior shall be as if the thread were created with the
detachstate attribute set to PTHREAD_CREATE_DETACHED. Supplying an
attributes structure with a detachstate attribute of
PTHREAD_CREATE_JOINABLE results in undefined behavior. The signal mask
of this thread is implementation-defined.

regards,
alexander.



More information about the cpp-threads mailing list