[jira] Commented: (TS-162) inconsistencies in the stats system - there are incorrect assumtions on sychronization between threads

["John Plevyak (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848447#action_12848447 ] 

John Plevyak commented on TS-162:
---------------------------------

I think there is  a race condition in this code if two instances of this code run at the same time.  First,
there is a race condition between the read of last_XXX and the write via swap and a possible write
on another thread.  Also there is a race between the two swaps and two other swaps on a different thread.
I think these can both be solved by using a CAS to update the last_XXX values and then using the
difference to update the sum/count via atomic increment.  While it is still possible that the count
and sum will be out of sync, that is always a problem, but at least updates will not get lost.

The sync problem is solvable as well with an additional loop during read and sequence numbers
of (updates started, updates ended) in a CAS updated variable attached to the global.

> inconsistencies in the stats system - there are incorrect assumtions on sychronization between threads
> ------------------------------------------------------------------------------------------------------
>
>                 Key: TS-162
>                 URL: https://issues.apache.org/jira/browse/TS-162
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Stats
>            Reporter: Bryan Call
>            Assignee: Bryan Call
>             Fix For: 2.0.0
>
>         Attachments: stats_bcall_001.diff
>
>
> There is a problem with the current stats being inconsistent.  The problem is that the net threads each have their own stats which they modify and the aggregation thread also modifies the same stat value.  There is no proper synchronization for this to work correctly.  The aggregation thread does an atomic swap to zero the net threads stat value, but the local thread doesn't use atomics and only increments the value.  This will lead to inconsistencies...
> A better design is to *only* have the net threads modify their local stats and have the aggregation thread handle totalling the values in a separate stat structure.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.