qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Ross (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-1160) Mutex/Lock avoidance in management agent interface
Date Mon, 30 Jun 2008 19:00:49 GMT

    [ 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.

View raw message