[jira] Commented: (QPID-1160) Mutex/Lock avoidance in management agent interface

["Ted Ross (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609334#action_12609334 ] 

Ted Ross commented on QPID-1160:
--------------------------------

The solution implemented is to use per-thread counters in the high-performance cases.  This removes the need for locking around write operations.

For each managed object, a statistics block is allocated for each new thread that accesses the statistics.  When the statistics are read (periodically or on demand), the per-thread blocks are aggregated into a single set of values prior to transmission.

The per-thread nature of the statistics is opaque to the managed code.  There is no change to the access API.

Issue:  The heart of this feature is the ability of C++ compilers to support "thread-local" variables.  This implementation uses the GCC notation for thread-local.  The single use of this notation (in cpp/src/qpid/management/ManagementObject.cpp:47) should be expanded to support the notations of other compilers as well.


> Mutex/Lock avoidance in management agent interface
> --------------------------------------------------
>
>                 Key: QPID-1160
>                 URL: https://issues.apache.org/jira/browse/QPID-1160
>             Project: Qpid
>          Issue Type: Improvement
>          Components: C++ Broker
>    Affects Versions: M3
>            Reporter: Ted Ross
>            Assignee: Ted Ross
>            Priority: Minor
>             Fix For: M3
>
>
> For management purposes, the C++ broker tracks statistics per-queue, exchange, and binding.  These statistics counters are necessarily incremented in the message forwarding fast-path and therefore must have very low performance cost.
> There is an issue with the multi-threaded nature of the C++ broker in that counter increments must be thread-safe or else they will become corrupt in a short time.  The current code base uses mutexes to protect the counters but this defeats the benefit of having multiple worker threads because counter contention causes the threads to stall while waiting for one another.
> This issue has been created to track the fix for this performance problem in the broker.

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