> On Nov. 4, 2015, 7:25 p.m., Neil Conway wrote:
> > Can we test that more thoroughly than just "make check"? e.g., if there's a
> > unit test that tries to enter this logic with multiple threads at once,
> > running that with gtest_repeat=1000 would be nice.
>
> Joseph Wu wrote:
> There are tons of methods in libprocess that call `process::initialize`
> as a side-effect, but at the same time, the libprocess test suite starts out
> with an essentially race-free init call (See:
> https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/tests/main.cpp#L52).
> So any `--gtest_repeat` or `--gtest_shuffle` won't actually test the init
> code. (The master and agent also call init once on startup.)
>
> I'm not sure how valuable it will be to, say, to spawn a bunch of threads
> that call `process::initialize`. Do you have any suggestions?
You could hackup tests/main.cpp::main() to test concurrent calls to
process::initialize() -- i.e.,
```if (getenv("TEST_LIBPROCESS_INIT")) { for (int i = 0; i < 100; i++) { /*
spawn thread */ process::initialize(); } } }```
- Neil
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39949/#review105115
-----------------------------------------------------------
On Nov. 4, 2015, 6:58 p.m., Joseph Wu wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39949/
> -----------------------------------------------------------
>
> (Updated Nov. 4, 2015, 6:58 p.m.)
>
>
> Review request for mesos, Benjamin Hindman and Joris Van Remoortere.
>
>
> Repository: mesos
>
>
> Description
> -------
>
> The initialization synchronization logic contains three conditions, which
> check:
> 1) Was `initialize` called and is it done?
> 2) Was `initialize` called and is it not done?
> 3) Are you the first to call `initialize`?
>
> Condition (3) uses `compare_exchange_strong` between `initialized` and
> `false`. This returns `true` (and sets `initialized` to true) iff the caller
> is the first to reach that expression.
>
> The second simultaneous caller of `initialize` will either satisify condition
> (2) or (3) and then wait on `initializing`. For the second caller, (2) and
> (3) are identical because `compare_exchange_strong` between `true` and
> `false` will always return false, thereby putting the second caller into the
> waiting loop.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/src/process.cpp
> a94712b9ac3b60fb047b3a5a4d84a56fa4d02313
>
> Diff: https://reviews.apache.org/r/39949/diff/
>
>
> Testing
> -------
>
> `make check`
>
>
> Thanks,
>
> Joseph Wu
>
>
