[lttng-dev] [PATCH 0/3] rculfhash: error checking fixes

[Eric Wong]

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?