[
https://issues.apache.org/jira/browse/DISPATCH-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872360#comment-16872360
]
ASF GitHub Bot commented on DISPATCH-1342:
------------------------------------------
franz1981 commented on issue #508: DISPATCH-1342 Replaced mutex with spin lock
on qd_message content
URL: https://github.com/apache/qpid-dispatch/pull/508#issuecomment-505450597
@astitcher Totally agree, that's why I haven't replaced the mutexes for any
possible use case; there are some requirements that need to be satisfied in
order to make this change effective (or feasable).
We need to:
- be sure no reentrancy is happening on the mutual exclusion zone (and it
seems the case, looking the code)
- be sure that the mutual exclusion zone is not held for too much time (to
be defined) and none is blocked on it
If both these requirements are met, only proper benchmarking and tests can
tell us if the spin lock is the right answer here. I would stick to something
that won't require OS arbitrations on the hot path anyway: OS is like burocrazy
and I won't bother it when user-space matters can already be solved with a more
predictable latencies
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Replaced mutex with spin lock on qd_message content
> ---------------------------------------------------
>
> Key: DISPATCH-1342
> URL: https://issues.apache.org/jira/browse/DISPATCH-1342
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Routing Engine
> Affects Versions: 1.7.0
> Reporter: Francesco Nigro
> Priority: Minor
>
> Given that qd_message creation and qd_message_free involves sys_mutex
> allocation/free and they are OS resources too, using spin locks will reduce
> the CPU/memory usage while performing such frequent operations.
> In addition it would make the router more reactive and resilient to OS thread
> scheduling while message->content is being concurrently accessed too, given
> that such accesses are meant to not last long and there is no need to involve
> OS arbitration to park/awake threads,
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
