On 3/25/2010 1:29 PM, Roedy Green wrote:
On Wed, 24 Mar 2010 16:21:29 -0700, Patricia Shanahan<pats@acm.org>
wrote, quoted or indirectly quoted someone who said :
It's difficult to know if the message was valid or not without an SSCCE.
you can see the complete code at
https://wush.net/websvn/mindprod/listing.php?repname=mindprod&path=/com/mindprod/vercheck/
it is a bit fat for a SSCCE.
Would have been nice of you to point out which of the twelve
source files elicited the complaint ... For others who may want
a look, VerCheck.java seems to be the culprit.
Roedy, I still don't know what's going on, but there's at least
one synchronization problem apparent in the code:
for ( int rowIndex = 0; rowIndex < ALL_ROWS.size(); rowIndex++ )
...
synchronized ( ALL_ROWS )
{
row = ALL_ROWS.get( rowIndex );
As the comment just before this loop says, rows might be deleted
from ALL_ROWS while this is running, meaning that rowIndex might
be out of range by the time you call get().
This doesn't appear closely related to a complaint about
synchronizing on row -- but I've often found, when confronted
by a mysterious problem, that it pays to clean up *all* the
other issues, even those that are "obviously unrelated."
By the way, if ALL_ROWS can be perturbed while the loop is
in progress, the iteration may miss rows (visit row 4, other
thread deletes row 2 and slides everything down one slot, visit
row 5 which used to be row 6, never visit the old row 5), or may
visit a row more than once (visit row 4, other thread inserts a
row after row 2 and slides everything up, visit row 5 which is
the same row just visited as 4). The comment indicates you don't
want to lock ALL_ROWS for the entire loop, but to keep the
iteration self-consistent you might want to do something like
lock ALL_ROWS, grab a snapshot with toArray(), unlock, and run
the iteration on the (private, stable) snapshot.
mechanisms for modifying/accessing this table. That way, you're actions
wrong either. The only truly difficult part of writing MT code is that