impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: impala::Mutex
Date Tue, 31 Oct 2017 17:21:43 GMT
Yea, we use our own mutex which is a simple wrapper around pthreads, but
also adds some instrumentation and debugging.

We have recently been thinking about switching to absl::Mutex from Google.
It has adaptive spinning, faster wake up for condition waiters, and a nice
API which avoids missed notify bugs. It also has the same or better
instrumentation support.

If you are going to switch I'd take a look at that implementation as well.

On Oct 31, 2017 10:12 AM, "Tim Armstrong" <tarmstrong@cloudera.com> wrote:

> The main case where we still use boost::mutex is when it's pair with a
> condition variable - we don't have any condition variable that integrates
> with SpinLock.
>
> Mutex does provide some stronger fairness guarantees, I think, but afaik we
> don't rely on that anywhere.
>
> On Tue, Oct 31, 2017 at 9:54 AM, Daniel Hecht <dhecht@cloudera.com> wrote:
>
> > 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 <
> > boroknagyz@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message