Re: [lttng-dev] [RFC] Deprecating RCU signal flavor

On Mon, Aug 21, 2023 at 11:43:32AM -0400, Mathieu Desnoyers wrote:
> On 8/15/23 08:38, Mathieu Desnoyers via lttng-dev wrote:
> > On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
> > > 
> > > After discussing it with Mathieu, we agree on the following 3 phases for
> > > deprecating the signal flavor:
> > > 
> > >   1) liburcu-signal will be implemented in term of liburcu-mb. The only
> > >   difference between the two flavors will be the public header files,
> > >   linked symbols and library name.  Note that this add a regression in
> > >   term of performance, since the implementation of liburcu-mb adds memory
> > >   barriers on the reader side which are not present in the original
> > >   liburcu-signal implementation.
> > > 
> > >   2) Adding the deprecated attribute to every public functions exposed by
> > >   the liburcu-signal flavor.  At this point, tests for liburcu-signal
> > >   will also be removed from the project.  There will be no more support
> > >   for this flavor.
> > > 
> > >   3) Removing the liburcu-signal flavor completely from the project.
> > > 
> > > Finally, here is a tentative versions release of mine for each phase:
> > > 
> > >   1) 0.15.0 [October 2023] (also TSAN support yay!)
> > > 
> > >   2) 0.15.1
> > > 
> > >   3) 0.16.0 || 1.0.0 (maybe a major bump since this is an API breaking
> > >   change)
> > 
> > There is a distinction between the version number of the liburcu project
> > (0.14) and the ABI soname for the shared objects. We may be able to do
> > step (3) without going to 1.0.0 (I don't see removal of the urcu-signal
> > flavor a strong enough motivation for hitting 1.0.0 yet).
> > 
> > Technically speaking, given that we would be removing the entire
> > liburcu-signal.so shared object, we would not be changing _symbols_
> > within an existing shared object, therefore I'm not even sure we need to
> > bump the soname for all the other remaining shared objects.
> 
> So after merging this commit:
> 
>     Phase 1 of deprecating liburcu-signal
>     The first phase of liburcu-signal deprecation consists of implementing
>     it in term of liburcu-mb. In other words, liburcu-signal is identical to
>     liburcu-mb at the exception of the function symbols and public header
>     files.
>     This is done by:
>       1) Removing the RCU_SIGNAL specific code in urcu.c
>       2) Making the RCU_MB specific code also specific to RCU_SIGNAL in
>       urcu.c
>       3) Rewriting _urcu_signal_read_unlock_update_and_wakeup to use a
>       atomic store with CMM_SEQ_CST instead of a store CMM_RELAXED with
>       cmm_barrier() around it. We could keep the explicit barriers, but that
>       would require to add some cmm_annotate annotations. Therefore, to be
>       less intrusive in a public header file, simply use the CMM_SEQ_CST
>       like for the mb flavor.
> 
> I notice that an application previously built against urcu-signal with
> _LGPL_SOURCE defined would have to be rebuilt, which would require a
> soname bump of urcu-signal.
> 
> So considering that this phase 1 is not really a "drop in" replacement,
> I favor removing the urcu-signal flavor entirely before the next release.
> 
> Thoughts ?

The replacement is liburcu-mb, correct?

I will need to change perfbook, but that should be an easy change,
plus sys_membarrier() is widely available by now.

							Thanx, Paul
_______________________________________________
lttng-dev mailing list
[email protected]
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev