Re: [classlib][luni] Provide a lock-free version of ReferenceQueue (HARMONY-6344)

[James Gan <ga...@gmail.com>]

Tim,

Thanks for you great comments! Actually, that's the purpose that I
sent this update to Harmony JIRA track. Please let me know if you
would prefer other approaches.

The performance difference is interesting and we need more time to
analysis it. Currently, we are suspecting volatile-write in poll()
method. In Wrapper version, only one volatile-write is needed. And in
NoWrapper version, there are two volatile-write. We will do some
profiling here.

I can ask others about how Reference come and go from the queue.
Though I'm not sure how typical it can be. If Harmony has a
macro-benchmark for this, please let me know.

For the last question, you are absolutely right. We should use another
object for this purpose. We used "this" for saving one synchronized
call in enqueue() method as shown below. But I now think your
suggestion is more reasonable. I will do a performance test for
verifying this.
		synchronized (this) {
			tail.next = n;
			tail = n;
			if (getQueueLen > 0) {
				notify();
			}
		}

We'll modify source code and return it to you asap. Thanks again!

On 11/5/09, Tim Ellison <t....@gmail.com> wrote:
> On 04/Nov/2009 03:30, James Gan (JIRA) wrote:
>> James Gan updated HARMONY-6344:
>> -------------------------------
>>
>>     Attachment: amino_rfq.zip
>>
>> In this new version, two reference queues are provides:
>>
>> 1. ReferenceQueueNodeWrapper
>>     Occupied more memory, better scalability
>> 2. ReferenceQueueNoNodeWrapper
>>     Occupied less memory, moderate scalability
>
> Thanks for the update James.
>
> As a general comment, while I appreciate the work and breadth of your
> contribution, it would be easier to follow as explicit patches against
> the current Harmony code, so I can see exactly what you are proposing we
> change.  That said, there is clearly some interesting work in here so
> I'm looking at it and thinking about how it could be used in Harmony.
>
> I suggest that we maintain a single implementation of Reference and
> ReferenceQueue for Harmony.  So let's decide early whether the Node
> wrapper version, or non-Node wrapper version is the right direction to go.
>
> Am I right to say that the Node wrapper is there to allow removal of the
> 'next' field from the Reference?  It seems to move the volatile field
> out to the ReferenceQueue$Node type, so it is unclear to me how that
> helps with the scalability overall.  Can you please explain?
>
> As you point out, the Node wrapper version will use more memory since it
> has a Node for each enqueued Reference.  It would be good to know some
> stats on how References come and go from the queue in a typical
> application (rather than microbenchmarks).
>
> Good to see that the remove() goes to sleep when the queue is empty now!
>
> [ I've not thought about it enough yet, but it seems a shame that the
> enqueue call has to synchronize on the entire ReferenceQueue in order to
> update the tail :-(
> ]
>
> Regards,
> Tim
>


-- 
Best Regards
James Gan
Current Project: Concurrent Building Block at http://amino-cbbs.sourceforge.net/
Blog: http://ganzhi.blogspot.com