[lttng-dev] [PATCH 0/3] rculfhash: error checking fixes
mathieu.desnoyers at efficios.com
Thu Jul 31 20:12:15 EDT 2014
----- Original Message -----
> From: "Eric Wong" <normalperson at yhbt.net>
> To: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> Cc: lttng-dev at lists.lttng.org, e at 80x24.org
> Sent: Thursday, July 31, 2014 6:25:45 PM
> Subject: Re: [lttng-dev] [PATCH 0/3] rculfhash: error checking fixes
> Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> > I do have to focus on other things at the moment, so you are welcome
> > to contribute those changes!
> OK, I'll try to get back to the rculfhash-using project in the next few
> weeks (but no promises)
> > > While we're on ABI/API changes, there's also several other changes
> > > I would like:
> > >
> > > * Remove the pthread_mutex_t requirement in the wfcqueue and lfstack
> > > structures.
> > Indeed, the mutex is not needed for all users. However, it allows us
> > to implement APIs that can be used by end users who want all
> > synchronization to be taken care of for them. In opposition, we
> > have the __ prefixed API which require to read and understand the
> > comments about synchronization requirements.
> > I wonder: what is the issue with having this mutex field in there ?
> > Is it space ? Having a dependency on pthread ? other ?
> Space. On my current project, I can use a union and put other stuff
> where the mutex is.
> > > I suppose we could implement limited new classes and layer the
> > > complete old ones on top to preserve ABI/API compatibility.
> > If we decide to remove the pthread_mutex_t field, this would indeed
> > be the way to do it.
> OK. Then the hardest part is probably naming the new API :)
I'm trying something with transparent union. See patch in separate
> > > * cmpxchg_double (cmpxchg16b on x86-64) so lfstack can use
> > > a lock-free stack for single pop operations. I'm currently using
> > > ck_stack from ConcurrencyKit, but generally prefer using the
> > > URCU APIs and it would be great if lfstack could support this
> > > on some arches.
> > Is there a way to implement a fallback for architectures that don't
> > have the double cmpxchg ?
> Unfortunately not. I have completely separate code paths, also cannot
> support early AMD64 machines which lack cmpxchg16b.
This means we would have to dynamically detect if the CPU supports
the instruction, and fallback to a different way of doing things.
So we would have to plan space (e.g. a union) for both the cmpxchg16b
and the fallback, with possibly a compiler flag that would allow
compiling out the fallback if the user really care about compactness,
and not about portability.
> > My intent is that if we start doing
> > optimizations for some architectures, the APIs can still be used
> > as is by applications ported to other architectures (modulo a
> > performance penality cost if unavoidable).
> Understandable. I wonder if regular cmpxchg with pointer-packing
> for the generation counter works. I'll have to try that.
Not sure I understand your idea here.
I wonder if we could simply fallback on a mutex for the fallback ?
> > > Do you have any timeline for a 0.9 release?
> > I would have liked to bring a major new feature like my RCU judy
> > array in 0.9, but unfortunately I keep getting side tracked on
> > other things :-/ I still need to rework the API and add more
> > tests. So no ETA for now.
> OK, no worries. I also noticed some rbtree work from the old days.
> Is that still on the horizon?
I don't think I want to push the rbtree code in production. It seems
to work, but I have a hard time convincing myself that I would be
able to debug it if an issue happens within this code. Moreover,
the RCU judy array seems more flexible in many ways than the rbtree,
so I prefer investing my time on Judy at the moment.
More information about the lttng-dev