[DTrace-devel] [PATCH v2 4/5] Implement the support code for generating aggregation data

[Kris Van Hees]

On Tue, Dec 01, 2020 at 06:02:23PM +0000, Eugene Loh wrote:
> On 11/30/2020 10:54 PM, Kris Van Hees wrote:
> 
> > On Mon, Nov 30, 2020 at 09:48:42PM -0800, Eugene Loh wrote:
> >> No.  Neither copy stores the seq#.  The seq# (in the current
> >> implementation) is shared by all copies of all aggregations (on a
> >> per-CPU basis).
> > Yes, sorry, I was mentally thinking about the earlier implementation I did
> > for this which used 2 map values.  Indeed, the aggregation data copies do not
> > contain the sequence number (although that is likely to change in the future
> > based on your suggestion anyway).
> 
> Thanks for the additional explanations, but I do not understand what you 
> say will "change in the future."  My suggestion was to have one sequence 
> number per aggregation, not per copy of each aggregation. The two copies 
> would continue to share a sequence number that is owned or stored by 
> neither one.

Yes, true.  But I do not think it changes anything about the fact that we
do want to refer to the two copies in some way that distinguishes them.
More below...

> > But either way, there is nothing wrong with
> > considering one to be primary and the other secondary.
> 
> It's misleading to introduce spurious concepts.

It is not a spurious concept and it is not meant to be misleading in any way.
The way the code is written, the update always happens in the same order: the
first copy is updated first, and the second copy is updated second.  So, the
primary update (initial update that commences the change from old value to
new value, if you will) occurs in the first copy, and once that one is done,
we update the second copy.  One can call that the secondary update.  You can
also consider it secondary because it is the copy that is used only while we
are in the process of updating the aggregation value from old to new value.

Let's agree to disagree?   I do not believe this is a material issue that
should be holding up the patch.

> > Is it necessary?
> > No, it is not.  But it is not wrong either.  And conceptually, the second
> > copy exists so that we can direct the consumer to that copy while we update
> > the first one, and then we switch things around again so we can update the
> > second copy in preparation for the next update (i.e. so that the consumer will
> > continue to see the correct data no matter what).
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel