[dtrace-discuss] What am I missing in the dtrace script?

[Brian D. Horn]

Bart Smaalders wrote:
> Brian D. Horn wrote:
>> Wee Yeh Tan wrote:
>>> On 7/13/07, Brian D. Horn <Brian.Horn at sun.com> wrote:
>>>> Ok, then the question becomes "Where is documented that aggregates are
>>>> MP safe, but scalars are
>>>> not MP safe?"
>>> Hah... I sort of saw that coming.  I recall seeing this somewhere
>>> though I cannot remember exactly where.  Didn't see it in Bryan's
>>> DTrace gotchas.
>>>
>>> Does this warrant a bug against the documentation?  Perhaps a note in
>>> the variables section saying that "Global variables are not MP safe."?
>>>
>> I don't know whether it is a bug or not yet.  I may have missed some
>> piece of documentation or seen old documentation.  It also begs the
>> question of "Why was it decided that scalars should not be MP safe?"
>> (assuming that is was decided as such!).
>
> The question here isn't whether "scalaers are mt-safe", it's whether
> or not the ++ and -- operators are atomic.
>
> Would you expect
>
> foo = foo + 1;
>
> to work safely?
>
> How about:
>
> bar = foo;
>
> foo = bar + 1;
>
> There's no implicit locking in DTrace.  Aggregations are specifically
> designed to be safe, and are documented as such:
>
>> For performance-related questions, aggregated data is often more 
> > useful than individual data points. DTrace provides several built-in
>> aggregating functions. When an aggregating function is applied to 
>> subsets of a collection of data, then applied again to the results of 
>> the analysis of those subsets, the results are identical to the 
>> results returned by the aggregating function when it is applied to 
>> the collection as a whole.
>>
>> The DTrace facility stores a running count of data items for 
>> aggregations. The aggregating functions store only the current 
>> intermediate result and the new element that the function is being 
>> applied to. The intermediate results are allocated on a per-CPU basis.
>> Because this allocation scheme does not require locks, the 
>> implementation is inherently scalable.

Ah ha!  This statement was what I was looking for and not finding.
I think a more clear statement should be in the documentation, but at 
least there is something!

Now, is in absolutely clear what *is* an aggregate?  I would think that 
global dynamic arrays
are not, correct?
>
>
>