Results 1 to 5 of 5

Thread: Atomics: reordering and memory semantics

  1. #1
    Join Date
    Feb 2011
    Posts
    354
    Thanks
    17
    Thanked 27 Times in 24 Posts
    Qt products
    Qt4 Qt5
    Platforms
    MacOS X Windows

    Default Atomics: reordering and memory semantics

    I'm now trying to find my feet in lock-free programming. In particular I am curious about possible reordering for different memory semantics.

    Consider the following example. There are two threads (producer and consumer). Release-acquire memory order is used for synchronization.
    Qt Code:
    1. #include <QCoreApplication>
    2. #include <QDebug>
    3. #include <QtConcurrent>
    4.  
    5. QAtomicPointer<QString> ptr;
    6. int data;
    7.  
    8. void producer()
    9. {
    10. QString* p = new QString("Hello");
    11. data = 42;
    12. ptr.storeRelease(p);
    13. }
    14.  
    15. void consumer()
    16. {
    17. QString* p2;
    18. //while (!(p2 = ptr.load())) // ?
    19. while (!(p2 = ptr.loadAcquire()))
    20. ;
    21. Q_ASSERT(*p2 == "Hello"); // never fires
    22. Q_ASSERT(data == 42); // never fires
    23. }
    24.  
    25.  
    26. int main(int argc, char *argv[])
    27. {
    28. QCoreApplication a(argc, argv);
    29. QtConcurrent::run(producer);
    30. QtConcurrent::run(consumer);
    31. return a.exec();
    32. }
    To copy to clipboard, switch view to plain text mode 

    I'm wondering why it is necessary to use release-acquire semantics here? What might happen if we used the relaxed load in consumer?
    Magicians do not exist

  2. #2
    Join Date
    Jan 2006
    Location
    Graz, Austria
    Posts
    8,416
    Thanks
    37
    Thanked 1,544 Times in 1,494 Posts
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: Atomics: reordering and memory semantics

    Why would the first assert be hit?

    You wait for p2 to be not null, which means producer has stored the pointer to its string. Which has the content that you are asserting on.

    The second assert could be hit is the write to data is reordered to after the setting of ptr and the other thread successfully loads from ptr before data has been written to, flushed to memory and synchronized into the cache of the second thread's execution unit.

    Assuming that there is more than one thread.

    Cheers,
    _

  3. #3
    Join Date
    Feb 2011
    Posts
    354
    Thanks
    17
    Thanked 27 Times in 24 Posts
    Qt products
    Qt4 Qt5
    Platforms
    MacOS X Windows

    Default Re: Atomics: reordering and memory semantics

    You wait for p2 to be not null, which means producer has stored the pointer to its string. Which has the content that you are asserting on.
    I don't understand. When p gets stored it's already initialized to new string("hello") and, as far as I understand, initialization of p can't be reordered past the store call as long as p is the argument (i.e. the store call depends on p). Or do you mean that only the pointer address is available, but the pointed data may be not synchronized?

    The second assert could be hit is the write to data is reordered to after the setting of ptr and the other thread successfully loads from ptr before data has been written to, flushed to memory and synchronized into the cache of the second thread's execution unit.
    Shouldn't ptr.storeRelease() prevent it from being reordered?

  4. #4
    Join Date
    Jan 2006
    Location
    Graz, Austria
    Posts
    8,416
    Thanks
    37
    Thanked 1,544 Times in 1,494 Posts
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: Atomics: reordering and memory semantics

    Quote Originally Posted by mentalmushroom View Post
    I don't understand. When p gets stored it's already initialized to new string("hello") and, as far as I understand, initialization of p can't be reordered past the store call as long as p is the argument (i.e. the store call depends on p).
    Exactly, hence it being impossible that the assert condition would not be true.

    Quote Originally Posted by mentalmushroom View Post
    Shouldn't ptr.storeRelease() prevent it from being reordered?
    That's the question, does that memory barrier effect other writes than the one it is protecting?

    Cheers,
    _

  5. #5
    Join Date
    Feb 2011
    Posts
    354
    Thanks
    17
    Thanked 27 Times in 24 Posts
    Qt products
    Qt4 Qt5
    Platforms
    MacOS X Windows

    Default Re: Atomics: reordering and memory semantics

    Exactly, hence it being impossible that the assert condition would not be true.
    Not sure if we are talking about the same thing. I mean what if relaxed order were used instead of acquire? Would it be unsafe to dereference the pointer in that case?

    That's the question, does that memory barrier effect other writes than the one it is protecting?
    If I understand it correctly, yes, but only if the other thread uses acquire (or stronger) to load the atomic variable. Otherwise, it may not see updates for non-atomic variables made by the release thread.

Similar Threads

  1. Reordering pixmap items in a QGraphicsScene
    By gerryw in forum Qt Programming
    Replies: 0
    Last Post: 8th December 2011, 07:53
  2. QListWidget - reordering
    By ComServant in forum Newbie
    Replies: 1
    Last Post: 24th August 2010, 20:03
  3. QTreeWidget Column Reordering
    By jimc1200 in forum Newbie
    Replies: 1
    Last Post: 8th January 2009, 09:51
  4. reordering QListWidgetItems of a QListWidget
    By OriginalCopy in forum Qt Programming
    Replies: 14
    Last Post: 4th December 2007, 16:49
  5. QThread call-once semantics?
    By brcain in forum Qt Programming
    Replies: 5
    Last Post: 20th October 2006, 22:25

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.