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:
    "1.9/7
    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
    1. Advertising

  2. "Dmitriy V'jukov" <> writes:

    > Latest C++0x draft N2723, 2008-08-25:
    > "1.9/7
    > 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?


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

    Anthony
    --
    Anthony Williams | Just Software Solutions Ltd
    Custom Software Development | http://www.justsoftwaresolutions.co.uk
    Registered in England, Company Number 5478976.
    Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
     
    Anthony Williams, Sep 8, 2008
    #2
    1. Advertising

  3. On 9 ÓÅÎÔ, 01:52, Anthony Williams <> wrote:
    > "Dmitriy V'jukov" <> writes:
    > > Latest C++0x draft N2723, 2008-08-25:
    > > "1.9/7
    > > 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?

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


    Oh! I've missed that moment.

    And what about non-relaxed atomics?
    Basically I can use following pattern for communication between
    threads:
    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
    #3
  4. "Dmitriy V'jukov" <> writes:

    > On 9 Ñент, 01:52, Anthony Williams <> wrote:
    >> "Dmitriy V'jukov" <> writes:
    >> > Latest C++0x draft N2723, 2008-08-25:
    >> > "1.9/7
    >> > 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?

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

    >
    > Oh! I've missed that moment.
    >
    > And what about non-relaxed atomics?
    > Basically I can use following pattern for communication between
    > threads:
    > 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?


    Probably because nobody thought it important enough to write a proposal.

    Anthony
    --
    Anthony Williams | Just Software Solutions Ltd
    Custom Software Development | http://www.justsoftwaresolutions.co.uk
    Registered in England, Company Number 5478976.
    Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
     
    Anthony Williams, Sep 9, 2008
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wee Bubba
    Replies:
    2
    Views:
    4,514
    Wee Bubba
    May 12, 2004
  2. Michael Pronath
    Replies:
    1
    Views:
    1,194
    Diez B. Roggisch
    Jan 3, 2005
  3. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    477
    Jack Orenstein
    Sep 18, 2005
  4. Weng Tianxiang
    Replies:
    2
    Views:
    671
    Jonathan Bromley
    Jan 30, 2007
  5. jumpz
    Replies:
    5
    Views:
    463
Loading...

Share This Page