[jira] [Created] (THRIFT-5162) ThreadManager tests fail in appveyor

["Jano Svitok (Jira)" <ji...@apache.org>]

Jano Svitok created THRIFT-5162:
-----------------------------------

             Summary: ThreadManager tests fail in appveyor
                 Key: THRIFT-5162
                 URL: https://issues.apache.org/jira/browse/THRIFT-5162
             Project: Thrift
          Issue Type: Bug
          Components: C++ - Library
    Affects Versions: 0.14.0
            Reporter: Jano Svitok


Log: [https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/builds/31898731/job/tec853o3sgg2vkht?fullLog=true#L6166]

Similar happens quite often but not always:

423: ThreadManager benchmark tests...
423: ThreadManager load test: worker count: 2 task count: 2000 delay: 5
423: loaded 2000 tasks to execute
423: activeCount = 2000
423: first start: 1052596 Last end: 1068271 min: 10ms max: 20ms average: 15.649ms
423: Success! expected time: 5000ms elapsed time: 15675ms
423: ThreadManager load test: worker count: 8 task count: 8000 delay: 5
423: loaded 8000 tasks to execute
423: activeCount = 7984
*423: Assertion failed: delta > 0, file c:\projects\thrift\lib\cpp\test\concurrency\ThreadManagerTests.h, line 162*
423/444 Test #423: concurrency_test ...................***Timeout 300.01 sec

I have not reproduced this locally, nor I tried to come up with a fix, nevertheless I suspect:

The assertion checks that test task duration was > 0. This calls sleep_ in ThreadManagerTest,.h that calls Monitor::wait() and that calls [std::condition_variable_any::wait_for(duration)|https://en.cppreference.com/w/cpp/thread/condition_variable_any/wait_for]. Note to this call says:

Atomically releases lock, blocks the current executing thread, and adds it to the list of threads waiting on \*this. The thread will be unblocked when notify_all() or notify_one() is executed, or when the relative timeout rel_time expires. IT MAY ALSO BE UNBLOCKED SPURIOUSLY. When unblocked, regardless of the reason, lock is reacquired and wait_for() exits.

If I am right, then the lib should check which of those three cases happened: 1. notify() called, 2. timeout elapsed 3. something else. This can be implemented using another bool member in Monitor, that is set to true in notify, and to false in waitXXX after condition returns true, and passing predicate returning this bool value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)