Re: Data sharing between threads in robocode
Matt Humphrey wrote:
"thYms" <dkalfa@gmail.com> wrote in message
news:1149432719.335821.197210@c74g2000cwc.googlegroups.com...
This is my first post to this grup and I have a little problem with
sharing a static object between threads. There is two thread class and
each of them refer to a static object of a third class through static
methods of the same class.
Problem is, when they refer to that static member, I realised that they
don't refer to same object although I declared it static.
As long as you have don't re-assign the static variable the threads
definately will be sharing the same instances. There are other reasons why
the data may not appear to change-- see below...
// This is the third class that I mentioned above
public class Repository {
public static ArrayList<String> enemyNames = new
ArrayList<String>();
public static HashMap<String, EnemyBot> enemies = new
HashMap<String, EnemyBot>();
public static HashMap<String, TeamBot> teammates = new
HashMap<String, TeamBot>();
public Repository() {
}
public static synchronized void
updateEnemyRepository(ScannedRobotEvent event, TeamRobot myRobot)
{
....
}
public class WarTorch extends TeamRobot
{
public void run()
{
while(true)
{
setTurnRadarRight(Integer.MAX_VALUE);
execute();
}
}
public void onScannedRobot(ScannedRobotEvent e)
{
// Here this class refer to the third class.
Repository.updateEnemyRepository(e, this);
for (Iterator it = Repository.enemyNames.iterator();
it.hasNext();) {
Object key = (String) it.next();
System.out.println(key + " - "
+Repository.enemies.get((String)key).getRobotName() + ", " +
Repository.enemies.get((String)key).getCoordinates());
System.out.println(e.getName());
}
}
Unfortunately, creating shared access to a resource is more complex than
this. You have correctly established that only one thread may update the
Enemy Repository at any time. What it seems you haven't protected against
is that one robot may be reading the repository while another is updating
it.
I didn't read his code, but based on your comments this sounds
like a classic reader-writer problem.
It's ok and even desireable to allow multiple readers on an
object. This is very efficeint and allows multiple thread to
access data with little overhead.
The writer thread however must clear all the readers out before
updating. While it's updating, no readers should access the data.
I think you need two locks to do this correctly (too lazy to
look). One is the write lock. All threads must check the write
lock. If it's not taken, then readers can proceed to the next
lock. If a writer thread has locked it, however, all readers
must stop and wait for the lock to be cleared.
The second lock is the reader lock. This is a more permissive
lock that simple counts the readers currently accessing the data.
The reader just increment this before accessing the data, then
decrement it after leaving. The write waits for this to be
cleared to 0 (zero readers accessing data), then it can proceed
with an update. After the writer is done updating, it clears the
write lock, allowing readers to access the data again.
I don't know how to implement this in Java directly. You may
have to implement objects that do this kind of locking, and
sychronize them (ie, you'll have two more objects in the code).
If anyone would like to help out, please feel free. I'll see if
I can find my systems book with the reader/writer problem in.
There are quite a number of way to solve this problem but they all have
trade-offs. What is the most important to you? Simplicity of the
synchronization method? Timeliness of data propagation? Correctness of
results? You are currently using an efficient method that sometimes
generates incorrect results. By fully synchronizing read-state access you
can have a very correct method that is very inefficient.
Er, I wouldn't call it "very" inefficient. Just a little more
overhead.