Quickie about Threads and double access to objects

[Mads]

I have a thread (A) that has functionality to maintain a Collection (probably a HashMap) through two methods. One adds an object, the other takes away one. However, it doesn't. Instead, a different thread (B) calls these whenever necessary.

The first thread (A) still needs to search the Collection quite a bit though. How do I do this the safest way? I know I could mark the Collection volatile, but the java tutorials still tells me I could be getting memory inconsistency errors.

I am also aware that some Collections are thread-safe, but I need the mapping of a HashMap. So finally here is my question, now that you're aware of the status-quo:
How do I make this operation completely thread-safe, the easiest way?

EDIT: My immidiate thoughts is to make both methods synchronized, as well as everywhere I want to look-up from thread (A). Problem is that it can be hundreds of times.
I would like to just make it volatile, but this specific passage makes me nervous:
"Using simple atomic variable access is more efficient than accessing these variables through synchronized code, but requires more care by the programmer to avoid memory consistency errors."

What is this? How does it even happen? How does one avoid it? Would that happen in my scenario? Most important of all, how can these errors even exist if volatile establishes a happens-before with any access to that field?

[65K]

Volatile is not sufficient here. You need to lock the collection if you want to modify and iterate it concurrently.
That isn't necessarily a problem. Try it, use a profiler to look out for blocked threads.

For organizing it differently, one would need more information about the background.
For example, you could queue in pending changes and let them execute from only one thread, or keep the collection encapsulated and set up a visitor for iterating from other threads.

[Mads]

Volatile is not sufficient here. You need to lock the collection if you want to modify and iterate it concurrently.
That isn't necessarily a problem. Try it, use a profiler to look out for blocked threads.

For organizing it differently, one would need more information about the background.
For example, you could queue in pending changes and let them execute from only one thread, or keep the collection encapsulated and set up a visitor for iterating from other threads.

How come is volatile not enough? Can you elaborate on this point, please? I do not comprehend where the problem lies.

It isn't necessarily a problem? I am trying to lay out structure on a piece of paper, so I can't just use a profiler. I am also not too fond
of organizing it differently. The Collection is for connections to clients. Thread (A) is a listener, that is just supplying work for thread (B), which is doing work. This is to keep from blocking the listener.

If I were to queue in changes, then one thread would supply those and the other take them away. That's a whole new concurrency problem. Would that be solved with a ConcurrentLinkedQueue?
Regardless, I am not fond of doing that. It seems far too complicated.

Games published by our own members! Check 'em out!

[Mads]

Actually, can I just use the http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentHashMap.html ?
Do I have to make that volatile, or is it completely safe in it's nature?

[65K]

Volatile is just to assure data visibility among multiple threads (and for atomic read/write access).
But you want collection methods to run atomic.

The idea for queuing changes was that at least one thread has only one synchronize point.

Is it for establishing connections ? Then I wouldn't worry at all.

I do heavily synchronizing for exchanging events in the main loops and did not see issues.

[65K]

The concurrent collections can be used without additional synchronizing.

[princec]

I'm sure there's a newfangled map in the concurrent package that is optimised for many-threads-reading, one-thread-writing. No time just at the mo to look it up.

Cas

[ra4king]

I'm pretty sure there is a ConcurrentHashMap somewhere......why yes there is

In fact, if anyone needs a concurrent collections class: this package is for you.

EDIT: Oops, fixed the first link.

[princec]

Ah yes! That's the one I meant.

Cas