Hashtable and Synchronization

[Bryan R. Meyer]

I've seen quite a few posts on this subject, but none definitively
answer my question. I am iterating over a Hashtable in one thread
while also adding elements to the Hashtable in another thread. On
occasion, a ConcurrentModificationException is being thrown as
expected. The JavaDocs explain that the Iterators are fail-fast and
also mention that Hashtable is synchronized.

Since Hashtable is already synchronized, it doesn't have to be placed
in a synchronization wrapper. If I place a synchronized block around
the code where I do the iteration through the Hashtable, will this
exception still be thrown? If so, what are my options for a
workaround?

Any insight would be appreciated.

Thanks,
Bryan

 

[Sudsy]

I've seen quite a few posts on this subject, but none definitively
answer my question. I am iterating over a Hashtable in one thread
while also adding elements to the Hashtable in another thread. On
occasion, a ConcurrentModificationException is being thrown as
expected. The JavaDocs explain that the Iterators are fail-fast and
also mention that Hashtable is synchronized.

It is synchronized. But you have to think about what that really
means, namely that only one thread can update the contents at any
moment in time. Atomic write access, if you will.

Since Hashtable is already synchronized, it doesn't have to be placed
in a synchronization wrapper. If I place a synchronized block around
the code where I do the iteration through the Hashtable, will this
exception still be thrown? If so, what are my options for a
workaround?

An iterator is a different animal. It allows you to "walk" through
the elements of the underlying Map. If there are alterations which
occur during processing then the fail-fast mechanism kicks in and
you receive an exception.
An iterator which locked the underlying object would prevent any
concurrent modification of the backing store, a severe performance
penalty.
So what is it that you're trying to accomplish?
Answering this simple question could lead you to the solution most
appropriate to your situation.
The answer you probably don't want to hear is "it depends..."
Sometimes you just need to throw away the existing Iterator and
instantiate a new one. I can't suggest an approach without knowing
more about the particular scenario. Are you working on an element
which you need to prevent other threads from accessing? Should you
be implementing a queue or stack such that conflicts can't occur?
Only you can answer these questions...

 

[Bryan R. Meyer]

So what is it that you're trying to accomplish?

I'm attempting to collect the most recent ping times from clients and
am placing the client names and ping times in a hashtable. This
hashtable can be updated continuously in one thread depending on when
the pings arrive. Every half minute in another thread, I am checking
when the last pings arrived from each client. I am using an Iterator
to run through the hashtable. I should note that each time this
thread runs a new iterator is being created. However, while I am
iterating, it is possible that new pings are being added to the
hashtable in the other thread.

Any suggestions? Perhaps I should go with some other data structure?

Thanks,
Bryan

 

[Chris Smith]

I'm attempting to collect the most recent ping times from clients and
am placing the client names and ping times in a hashtable. This
hashtable can be updated continuously in one thread depending on when
the pings arrive. Every half minute in another thread, I am checking
when the last pings arrived from each client. I am using an Iterator
to run through the hashtable. I should note that each time this
thread runs a new iterator is being created. However, while I am
iterating, it is possible that new pings are being added to the
hashtable in the other thread.

If you surround the iteration code with a 'synchronized' block, that
will indeed prevent the ConcurrentModification exception. It will also
prevent the hashtable from being updated during the time that you are
iterating over it; that is, the update thread will block until the the
thread that's iterating is done.

That seems to be a reasonable answer, unless you spend a lot of time
during the iterating. If you spend a lot of time iterating, you might
consider another answer, such as creating a snapshot of the Hashtable,
and then iterating over that. That way, the real data could continue to
be updated while you're working with your snapshot.

It would also be possible to implement your own hashing container that
provides a different behavior than fail-fast for iteration, but it could
get very complex to do this right. Save that one for last, only if no
other solution is valid.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Bryan R. Meyer]

Chris,

Thanks for the reply. Iteration time is not very large, and this
exception hasn't been generated often. It seems random, but when it
does happen, it plays havoc with my program. I will try the
synchronized block.

Bryan

 

[Filip Larsen]

Bryan R. Meyer wrote

I'm attempting to collect the most recent ping times from clients and
am placing the client names and ping times in a hashtable. This
hashtable can be updated continuously in one thread depending on when
the pings arrive. Every half minute in another thread, I am checking
when the last pings arrived from each client. I am using an Iterator
to run through the hashtable.

Another option, in addition to those already mentioned, could be to do
whatever you do in the iteration during each update instead. A very simple
example would be to find the latest ping time, which can be done simply by
storing the relevant data each time a ping is received. Another example
could be to calculate the average ping time, which can be done for each ping
by first substract the old ping value and then add the new value to an
accumulated ping variable. Or, if you need to order the clients according to
time of last ping, you can use a heap structure that is updated after each
ping. I guess you get the picture here.


Regards,

 

[soft-eng]

It would also be possible to implement your own hashing container that
provides a different behavior than fail-fast for iteration, but it could

If he doesn't need fail-fast, and is ok with non-deterministic
iteration, the hashtable enumerations already allow that.