Add tests to SingleThreadedSchedulerClient() and document the memory model #13247

pull skeees wants to merge 3 commits into bitcoin:master from skeees:scheduler-tests changing 3 files +72 −4
  1. skeees commented at 7:49 PM on May 16, 2018: contributor

    As discussed in #13023 I've split this test out into a separate pr

    This test (and documentation update) makes explicit the guarantee (previously undefined, but implied by the 'SingleThreaded' in SingleThreadedSchedulerClient()) - that callbacks pushed to the SingleThreadedSchedulerClient() obey the single threaded model for memory and execution - specifically, the callbacks are executed fully and in order, and even in cases where a subsequent callback is executed by a different thread, sequential consistency of memory for all threads executing these callbacks is maintained.

    Maintaining memory consistency should make the api more developer friendly - especially for users of the validationinterface. To the extent that there are performance implications from this decision, these are not currently present in practice because all use of this scheduler happens on a single thread currently, furthermore the lock should guarantee consistency across callback executions even when callbacks are executed by multiple threads (as the test does).

  2. TheBlueMatt commented at 7:50 PM on May 16, 2018: member

    Can you also note the memory model in validationinterface, since that's the "real" API here.

  3. skeees commented at 8:20 PM on May 16, 2018: contributor

    Updated

  4. skeees force-pushed on May 16, 2018
  5. fanquake added the label Tests on May 16, 2018
  6. in src/test/scheduler_tests.cpp:128 in 9c9e20356a outdated
     123 | +    // create more threads than queues
     124 | +    // if the queues only permit execution of one task at once then
     125 | +    // the extra threads should effectively be doing nothing
     126 | +    // if they don't we'll get out of order behaviour
     127 | +    boost::thread_group threads;
     128 | +    for (int i = 0; i < 5; i++) {
    


    Empact commented at 11:53 PM on May 16, 2018:

    nit: ++i is preferred according to the developer-notes.

  7. in src/test/scheduler_tests.cpp:154 in 9c9e20356a outdated
     149 | +    // finish up
     150 | +    scheduler.stop(true);
     151 | +    threads.join_all();
     152 | +
     153 | +    BOOST_CHECK_EQUAL(counter1, 100);
     154 | +    BOOST_CHECK_EQUAL(counter2, 100);
    


    Empact commented at 12:10 AM on May 17, 2018:

    Might want to label this a sanity check, to make it more clear that the 141/145 checks are the meat of the test.

  8. in src/validationinterface.h:63 in 9c9e20356a outdated
      58 | + *
      59 | + * Events are totally ordered - that is - all CValidationInterface() subscribers
      60 | + * will receive callbacks in the same order. Furthermore, each ValidationInterface
      61 | + * subscriber may assume that callbacks effectively run in a single thread with
      62 | + * single-threaded memory consistency. That is, for a given ValidationInterface()
      63 | + * instantiation, each callback will complete before
    


    Empact commented at 12:14 AM on May 17, 2018:

    nit: whitespace

  9. in src/validationinterface.h:59 in 9c9e20356a outdated
      52 | @@ -53,6 +53,19 @@ void CallFunctionInValidationInterfaceQueue(std::function<void ()> func);
      53 |   */
      54 |  void SyncWithValidationInterfaceQueue();
      55 |  
      56 | +/**
      57 | + * Implement this to subscribe to validation events
      58 | + *
      59 | + * Events are totally ordered - that is - all CValidationInterface() subscribers
    


    TheBlueMatt commented at 3:32 PM on May 17, 2018:

    The wording here seems to imply order between different subscribers.

  10. Add Unit Test for SingleThreadedSchedulerClient
    Ensures ordering of callbacks within a SingleThreadedSchedulerClient
    with respect to each other
    9994d01d8b
  11. skeees force-pushed on May 18, 2018
  12. fanquake added this to the milestone 0.17.0 on Jul 18, 2018
  13. MarcoFalke requested review from TheBlueMatt on Jul 22, 2018
  14. DrahtBot commented at 11:49 PM on July 22, 2018: member

    <!--5d09a71f8925f3f132321140b44b946d-->The last travis run for this pull request was 65 days ago and is thus outdated. To trigger a fresh travis build, this pull request should be closed and re-opened.

  15. DrahtBot closed this on Jul 22, 2018

  16. DrahtBot reopened this on Jul 22, 2018

  17. fanquake added this to the "Blockers" column in a project

  18. MarcoFalke removed this from the milestone 0.17.0 on Jul 30, 2018
  19. jamesob approved
  20. in src/scheduler.h:91 in 9b6848e80e outdated
      85 | @@ -86,9 +86,9 @@ class CScheduler
      86 |  
      87 |  /**
      88 |   * Class used by CScheduler clients which may schedule multiple jobs
      89 | - * which are required to be run serially. Does not require such jobs
      90 | - * to be executed on the same thread, but no two jobs will be executed
      91 | - * at the same time.
      92 | + * which are required to be run serially. Jobs may not be run on the
      93 | + * same thread, but no two jobs will be executed
      94 | + * at the same time and memory will be sequentially consistent.
    


    TheBlueMatt commented at 10:22 PM on July 30, 2018:

    Sequentially consistent of release-acquire? I think release-acquire is all we should guarantee.


    skeees commented at 11:42 PM on July 30, 2018:

    updated, thanks

  21. Update documentation for SingleThreadedSchedulerClient() to specify the memory model b296b425a7
  22. Update ValidationInterface() documentation to explicitly specify threading and memory model cbeaa91dbb
  23. skeees force-pushed on Jul 30, 2018
  24. skeees commented at 11:44 PM on July 30, 2018: contributor

    Updated to address @TheBlueMatt (diff is a comment change only)

  25. skeees commented at 5:30 PM on July 31, 2018: contributor

    Test failure was unrelated and now resolved

  26. MarcoFalke merged this on Aug 1, 2018
  27. MarcoFalke closed this on Aug 1, 2018

  28. MarcoFalke referenced this in commit e83d82a85c on Aug 1, 2018
  29. fanquake removed this from the "Blockers" column in a project

  30. laanwj referenced this in commit c1cba35725 on Aug 2, 2018
  31. PastaPastaPasta referenced this in commit c5af021d59 on Jul 17, 2020
  32. PastaPastaPasta referenced this in commit 827602c8f4 on Jul 17, 2020
  33. PastaPastaPasta referenced this in commit 82d64aef95 on Jul 17, 2020
  34. PastaPastaPasta referenced this in commit c0b610aec0 on Jul 17, 2020
  35. PastaPastaPasta referenced this in commit f9aa9ad39f on Jul 17, 2020
  36. PastaPastaPasta referenced this in commit d340124612 on Jul 17, 2020
  37. random-zebra referenced this in commit b993c56afe on Apr 4, 2021
  38. DrahtBot locked this on Dec 16, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-14 21:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me