Leon Rosenberg wrote:
On Fri, Dec 5, 2008 at 9:50 AM, Oliver Schoett
<[EMAIL PROTECTED]> wrote:
Martin Gainty wrote:
so the solution is put all updates/inserts to the arraylist into a
synchronized method?
You must synchronize all read and write methods, because nothing may run in
parallel with a write method, and so read methods must be prevented from
executing if a write method runs already.
The only exception is if you can ensure that the ArrayList is read-only at
some point in your program (e. g., after a setup phase).
Arguing that the size() function cannot loop does not help, because the size
function could be called internally in an infinite loop (this would be
visible in the call stack).
Oliver,
I'm very sorry but i really don't see your point.
The only possible need to synchronize access to ArrayList.size is when
you a) access the list from different threads and b) need the result
to be exact. Neither was the fact in my original post, in fact, as we
already resolved it, the vm was getting out of old gen space and
afterwards just behaving weird.
Three points:
(1) In the absence of call stack information, we do not know whether the
size() calls showing up in the thread dumps come from the application or
are internal calls from some other ArrayList function that may be in an
infinite loop.
(2) That size() cannot loop may be a property of the current
implementation; it is not guaranteed by the API.
(3) In general, when you query the size, you then want to do something
according to the value you got. Unless there is a synchronizaton block
around the size call and the subsequent action that guarantees that
there are no intervening changes to the ArrayList, the size call is
useless, as the ArrayList may change arbitrarily between the size call
and the action. Thus in general, even "harmless" query functions will
appear inside synchronized sections together with the actions that use
the result value. (The only exception I see is where the result value is
just used for information and does not control any action).
Regards,
Oliver Schoett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
