3

I am making a 2 player videogame, and the oponent's position gets updated on a thread, because it has a socket that is continuously listening. What I want to share is position and rotation.

As it is a videogame I don't want the main thread to be blocked (or be just the minimum time possible) and I don't want the performance to be affected. So from what I've seen to share this info the normal thing to do would be something like

class sharedinfo
{
   public synchronized read();
   public synchronized write();
}

but this would block the read in the main thread (the same that draws the videogame) until the three values (or even more info in the future are written) are written, and also I've read that synchronized is very expensive (also it is important to say this game is for android also, so performance is very important).

But I was thinking that maybe having sharedInfo inside an AtomicReference and eliminating synchronized would make it more efficient, because it would only stop when the reference itself is being updated (the write would not exist, I would create a new object and put it on the atomicreference), also they say that atomic* use hardware operations and are more efficient than synchronized.

What do you think?

dyeray
  • 1,056
  • 6
  • 17

1 Answers1

1

Consider using a queue for this, Java has some nice concurrent queue implementations. Look up the BlockingQueue interface in java.util.concurrent, and who implements it. Chances are you fill find strategies implemented that you hadn't even considered.

Before you know it, you will want to communicate more than just positions between your threads, and with a queue you can stick different type of objects in there, maybe at different priorities, etc.

If in your code you use Interfaces (like Queue or BlockingQueue) as much as possible (i.e. anywhere but the place where the specific instance is constructed), it is really easy to swap out what exact type of Queue you are using, if you need different functionality, or just want to play around.

Jan Schiefer
  • 1,003
  • 7
  • 15
  • I had thought about using a queue, I think that it is very good for sending "events" like "I finished the game", "I used this/that ability", but for the position you are only worried about the last send position, so I was thinking that if one player has more processing power than the other it could flood the other. Even if you take care for not flooding your oponent, I thought it could be wasting resources getting to the place where you update your logic and having to extract 6 or 8 or whatever position/angle elements and only using the last one. Is my reasoning correct? – dyeray Nov 17 '12 at 06:41
  • I think you are raising some very valid concerns. For most of those, there is an type of queue that implements it, like bounded queues for the amount of old updates that you care about, blocking or non-blocking to deal with flooding... Whatever you choose, I would recommend writing a few unit tests that start multiple threads and throw stuff at each other. Then you can play with different options and see how they behave. If you are interested in concurrent programming in Java, get the book "Java Concurrency in Practice" by Brian Goetz. Steal it if you have to, it's that good. – Jan Schiefer Nov 17 '12 at 07:41