We have impala::SpinLock, which works with lock_guard, unique_lock, etc. It's adaptive so it will block after spinning for a little bit, and seems to work well in most cases. It's built on gutil, which also has some tracing we could enable. Any reason not to stick with that?
I haven't looked at Kudu's implementation in a while and am not opposed to using it if there's a good reason to switch. But I think maybe we should first figure out how to better share code with Kudu so that we don't just continue to fork general purpose utility code (which is what we're currently doing). On Tue, Oct 31, 2017 at 9:47 AM, Zoltan Borok-Nagy <borokna...@cloudera.com> wrote: > Hi Everyone, > > I started to review the usage of synchronization primitives in Impala and > created this JIRA issue: https://issues.apache.org/jira/browse/IMPALA-6125 > > After some chat with Tim, we talked about the possibilities of reducing the > dependence of boost. Since now we are using C++11, there are std::thread, > std::mutex, and std::condition_variable in the standard library. > > On the other hand, the standard library likes to use exceptions in case of > errors, and AFAIK we don't like exceptions in Impala. Also, we already have > utility classes like ConditionVariable in the code base. In the kudu/util > directory, there is a Mutex class which is more conform to the Impala code > conventions than boost and the standard library. It also checks the > ownership of the mutex in debug mode, which can be useful for detecting > bugs. > > Do you think it would be a good idea to create our own Mutex implementation > based on kudu/util/mutex? > > BR, > Zoltan >
