You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Ted Ross (JIRA)" <qp...@incubator.apache.org> on 2008/06/30 16:53:45 UTC
[jira] Created: (QPID-1160) Mutex/Lock avoidance in management
agent interface
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.
[jira] Commented: (QPID-1160) Mutex/Lock avoidance in management
agent interface
Posted by "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.
[jira] Resolved: (QPID-1160) Mutex/Lock avoidance in management
agent interface
Posted by "Ted Ross (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ted Ross resolved QPID-1160.
----------------------------
Resolution: Fixed
> 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.
[jira] Commented: (QPID-1160) Mutex/Lock avoidance in management
agent interface
Posted by "Steve Huston (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622883#action_12622883 ]
Steve Huston commented on QPID-1160:
------------------------------------
As part of the Windows port I added a QPID_TSS macro to qpid/sys/Thread.h ala:
#ifdef _WIN32
# define QPID_TSS __declspec(thread)
#elif defined (gcc)
# define QPID_TSS __thread
#else
# define QPID_TSS
#endif
It goes against the guideline for not doing platform-specific ifdefs, but does solve the problem for these two compilers. Is this acceptable?
> 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.
[jira] Commented: (QPID-1160) Mutex/Lock avoidance in management
agent interface
Posted by "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=12622888#action_12622888 ]
Ted Ross commented on QPID-1160:
--------------------------------
Steve,
I think this is necessary, thanks for pointing it out. As long as the platform-specific ifdef is isolated to a single place in qpid/sys, I think it's OK.
Why did you call it QPID_TSS? Might QPID_THREAD_LOCAL be clearer?
-Ted
> 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.
[jira] Commented: (QPID-1160) Mutex/Lock avoidance in management
agent interface
Posted by "Steve Huston (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622892#action_12622892 ]
Steve Huston commented on QPID-1160:
------------------------------------
Yes, QPID_THREAD_LOCAL is possibly clearer. I'm just used to thinking TSS. Plus, I'm not much of a typist ;-)
If you'd rather it be QPID_THREAD_LOCAL I'll change it; in either event I'll submit the patch to this issue.
> 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.