[lttng-dev] [PATCH 0/3] rculfhash: error checking fixes
normalperson at yhbt.net
Thu Jul 31 18:25:45 EDT 2014
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 :)
> > * 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.
> 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.
> > 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?
More information about the lttng-dev