Re: Data sharing between threads in robocode

Matt Humphrey wrote:

"thYms" <dkalfa@xxxxxxxxx> wrote in message news:1149432719.335821.197210@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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.
.

Relevant Pages

  • [RFC PATCH] Writer-biased low-latency rwlock v8
    ... same as the writer fast path you did: I expect all bits to be 0. ... Therefore, if there are many readers at once, I use the slow path even ... though there is not "real" contention on the lock. ...
    (Linux-Kernel)
  • Re: [RFC PATCH] Fair low-latency rwlock v5
    ... If the lock is uncontended, but is not in the current CPU's caches, ... Fair low-latency rwlock provides fairness for writers against reader threads, ... but lets softirq and irq readers in even when there are subscribed writers ... Added contention delays performance tests for thread and interrupt contexts to ...
    (Linux-Kernel)
  • [RFC PATCH] Fair low-latency rwlock v5
    ... If the lock is uncontended, but is not in the current CPU's caches, ... Fair low-latency rwlock provides fairness for writers against reader threads, ... but lets softirq and irq readers in even when there are subscribed writers ... Added contention delays performance tests for thread and interrupt contexts to ...
    (Linux-Kernel)
  • [Enhancement] : Improvement suggestion in read-write spinlock code
    ... This is to suggest and discuss the enhancement in spinlock code. ... is greater than equal to 1, go ahead and try to acquire the lock. ... My reasoning for this is that we should only come out of loop and try ... so at value 1 there is nospace for more readers in CR ...
    (Linux-Kernel)
  • Re: Spinlocks waiting with interrupts disabled / preempt disabled.
    ... seems to have been that many threads went after the read lock, ... rwlock_t will allow readers in while readers hold the lock, ... This would be your best option for you kabi constrained .16 kernel. ... Contention by writers now keeps readers out, ...
    (Linux-Kernel)