> With my proposed change to the meaning of volatile, a programmer can
> declare the
> next field to be volatile and eliminate the inner lock.
Actually, and most importantly, the object field also needs to be
volatile so that the client making the call to poll can see the object
it just got. The field could almost instead be final, which would
ordinarily be cheaper, except that you couldn't null it out after
returning it. Even this wouldn't be so bad since most nodes themselves
quickly become garbage, except that the head node would retain the
last returned object even when the queue is empty. This wouldn't
always be acceptable to users of the queue. This is the reason that I
didn't list it in the book as:
class Node { final Object object; volatile Node next; }.
and then omit inner locks.
Well, the other reason is that it would rely on a property of final
that goes enough beyond current (lack of) rules that I felt
uncomfortable listing it in book as such.
-Doug
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT