Mathieu Desnoyers <[email protected]> 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? _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
