Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Quickie about Threads and double access to objects  (Read 1515 times)
0 Members and 1 Guest are viewing this topic.
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Posted 2012-06-05 05:16:42 »

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?

Offline 65K
« Reply #1 - Posted 2012-06-05 06:28:33 »

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.

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #2 - Posted 2012-06-05 07:13:30 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #3 - Posted 2012-06-05 07:22:14 »

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?

Offline 65K
« Reply #4 - Posted 2012-06-05 07:23:59 »

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.

Offline 65K
« Reply #5 - Posted 2012-06-05 07:27:32 »

The concurrent collections can be used without additional synchronizing.

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2012-06-05 08:41:42 »

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 Smiley

Offline ra4king

JGO Kernel


Medals: 356
Projects: 3
Exp: 5 years


I'm the King!


« Reply #7 - Posted 2012-06-05 08:59:54 »

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

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

EDIT: Oops, fixed the first link.

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2012-06-05 09:22:42 »

Ah yes! That's the one I meant.

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (33 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (51 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (59 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!