C++0x: Communication with signal handler

Discussion in 'C++' started by Dmitriy V'jukov, Sep 8, 2008.

  1. Latest C++0x draft N2723, 2008-08-25:
    When the processing of the abstract machine is interrupted by receipt
    of a signal, the values of objects which
    are neither
    — of type volatile std::sig_atomic_t nor
    — lock-free atomic objects (29.2)
    are unspecified, and the value of any object not in either of these
    two categories that is modified by the
    handler becomes undefined."

    It looks quite strange. Then what atomic_signal_fence() is all about?
    Proposal N2731 on bidirectional fences (which includes
    atomic_signal_fence()) is not going to change 1.9/7.
    I think that proposal on bidirectional fences must also change 1.9/7
    to allow usage of plain variables for thread-signal communication
    provided that plain variables are properly synchronized with
    atomic_signal/thread_fences and/or atomic variables.

    Dmitriy V'jukov
    Dmitriy V'jukov, Sep 8, 2008
    1. Advertisements

  2. atomic_signal_fence provides ordering for relaxed atomics and volatile
    std::sig_atomic_t variables.

    Anthony Williams, Sep 8, 2008
    1. Advertisements

  3. Oh! I've missed that moment.

    And what about non-relaxed atomics?
    Basically I can use following pattern for communication between
    int data;
    atomic<int> flag;
    void thread1() {
    data = 1;
    flag.store(1, release);
    void thread2() {
    if (flag.load(acquire))
    assert(1 == data);

    Why I can't use this pattern for thread/signal communication?

    Dmitriy V'jukov
    Dmitriy V'jukov, Sep 9, 2008
  4. Probably because nobody thought it important enough to write a proposal.

    Anthony Williams, Sep 9, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.