Claudio Martella commented on GIRAPH-185:

The performance of concurrentlinkedqueue is going to be faster than a 
synchronized block as it's just a CAS operation on the tail pointer, at least 
for the add() method which adds to the tail of the queue. Also, arrayList in 
any case should be slower on adding elements as it requires the memory 
expansion and copying when the allocated memory is exhausted.
Iteration could indeed be a bit slower than an arrayList because of cache.

The memory overhead of each entry of the queue is indeed something that should 
be investigated. Worst case, one might think of copying the 
concurrentlinkedqueue implementation and remove the "prev" pointer which we 
don't need.
> Improve concurrency of putMsg / putMsgList
> ------------------------------------------
>                 Key: GIRAPH-185
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-185
>             Project: Giraph
>          Issue Type: Improvement
>          Components: graph
>    Affects Versions: 0.2.0
>            Reporter: Bo Wang
>            Assignee: Bo Wang
>             Fix For: 0.2.0
>         Attachments: GIRAPH-185.patch, GIRAPH-185.patch
>   Original Estimate: 2h
>  Remaining Estimate: 2h
> Currently in putMsg / putMsgList, a synchronized closure is used to protect 
> the whole transientInMessages when adding the new message. This lock prevents 
> other concurrent calls to putMsg/putMsgList and increases the response time. 
> We should use fine-grain locks to allow high concurrency in message 
> communication.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to