> On Nov. 7, 2015, 7:35 p.m., Ben Mahler wrote: > > 3rdparty/libprocess/src/process.cpp, lines 742-770 > > <https://reviews.apache.org/r/39949/diff/2/?file=1115936#file1115936line742> > > > > Could we document why we're not just using process::Once to clean this > > up? > > > > The only thing that comes to mind is the performance implications of > > changing from a spin loop to the mutex condition variable approach, given > > that this gets called all over the place.
I don't know why we don't use `Once` either. Perhaps because the synchronization logic predates `Once`? (And that wouldn't be a very good reason.) `Once` was added April 30, 2012: https://github.com/apache/mesos/commit/6c3b107e4e02d5ba0673eb3145d71ec9d256a639#diff-0eebc8689450916990abe080d86c2acb The libprocess synchronization logic has been mostly unchanged since June 04, 2011: https://github.com/apache/mesos/commit/cd757cf75637c92c438bf4cd22f21ba1b5be702f#diff-128d3b56fc8c9ec0176fdbadcfd11fc2 - Joseph ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39949/#review105602 ----------------------------------------------------------- On Nov. 6, 2015, 2:11 p.m., Joseph Wu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/39949/ > ----------------------------------------------------------- > > (Updated Nov. 6, 2015, 2:11 p.m.) > > > Review request for mesos, Benjamin Hindman, Joris Van Remoortere, and Neil > Conway. > > > Bugs: MESOS-3820 > https://issues.apache.org/jira/browse/MESOS-3820 > > > Repository: mesos > > > Description > ------- > > * Renamed `initialized` to `initialize_started`. > * Renamed `initializing` to `initialize_complete`. > * Removed the (2) condition, described below: > > 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` > > Replaced `process::initialize();` in `3rdparty/libprocess/src/tests/main.cpp` > with: > ``` > > const size_t numThreads = 50; > > std::thread* runningThreads[numThreads]; > > // Create additional threads. > for (size_t i = 0; i < numThreads; i++) { > runningThreads[i] = new std::thread([]() { > process::initialize(); > }); > } > > for (size_t i = 0; i < numThreads; i++) { > runningThreads[i]->join(); > delete runningThreads[i]; > } > ``` > (Also added `#include <thread>` to the header). > > Rebuilt `libprocess-tests` with the modification and ran it a few times. > `3rdparty/libprocess/libprocess-tests` > > > Thanks, > > Joseph Wu > >
