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

[Mathieu Desnoyers]

----- 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)

Great!

> 
> > > 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
email.

> 
> > > * 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.

Thanks!

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com