[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 5:35:00 PM
> Subject: Re: [lttng-dev] [PATCH 0/3] rculfhash: error checking fixes
> 
> Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> > All merged, thanks! Sorry for the delay, the past month has been quite
> > busy.
> 
> No worries.  I've been sidetracked into other projects, too.
> 
> > Eric Wong <normalperson at yhbt.net> wrote:
> > > In the future, it would also be nice if the alloc_bucket_table behavior
> > > could fail gracefully on ENOMEM, but that would break ABI...
> > 
> > We could pull this into master for an eventual 0.9 release. We already
> > have a few ABI breaking changes that require us to bump the ABI in
> > master.
> 
> OK.  I'll try to work on that (unless you have more time now, I've
> been sidetracked too :x)

I do have to focus on other things at the moment, so you are welcome
to contribute those changes!

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

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

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

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

Thanks!

Mathieu

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