On 8/23/23 10:47, Paul E. McKenney wrote:
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?
After merging this "phase 1" of the removal, I noticed that we would need
to require applications built with _LGPL_SOURCE defined and using
liburcu-signal to be rebuilt, which would require a major library soname
bump, which I would prefer to avoid unless necessary.
Therefore, I went ahead and pushed additional commits in the master branch
which completely remove liburcu-signal from the tree. Therefore, the next
release of liburcu will not have the liburcu-signal header files nor its
library shared objects.
I will need to change perfbook, but that should be an easy change,
plus sys_membarrier() is widely available by now.
Users of liburcu-signal would be expected to migrate to liburcu-memb, which
relies on membarrier to achieve similar performance, but with lower-overhead
grace periods.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
