Fix flakyness in TestWatchpointMultipleThreads
authorPavel Labath <labath@google.com>
Wed, 30 Mar 2016 08:43:54 +0000 (08:43 +0000)
committerPavel Labath <labath@google.com>
Wed, 30 Mar 2016 08:43:54 +0000 (08:43 +0000)
commitec62c0559fa6ccad76ee22e98d8a274995675080
tree38b143f96bb2549ac31f003dea8d512ae005592e
parent8e06a10d1f68f3d7990295806f1254b2d3ff09fc
Fix flakyness in TestWatchpointMultipleThreads

Summary:
the inferior in the test deliberately does not lock a mutex when accessing the watched variable.
The reason for that is unclear as, based on the logs, the original intention of the test was to
check whether watchpoints get propagated to newly created threads, which should work fine even
with a mutex. Furthermore, in the unlikely event (which I have still observed happening from time
to time) that two threads do manage the execute the "critical section" simultaneously, the test
will fail, as it is expecting the watchpoint "hit count" to be 1, but in this case it will be 2.

Given this, I have simply chose to lock the mutex always, so that we have more predictible
behavior. Watchpoints being hit simultaneously is still (and correctly!) tested by
TestConcurrentEvents.

Reviewers: clayborg, jingham

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D18558

llvm-svn: 264846
lldb/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
lldb/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp