[
https://issues.apache.org/jira/browse/THRIFT-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074157#comment-17074157
]
Jens Geyer commented on THRIFT-5162:
------------------------------------
Possible relation to THRIFT-4963 maybe?
> 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
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
