1

On android I have one hashtable and two thread which can access to that. - UI thread access to it with containsKey, get and put - other thread access to it with containsKey, get and put and an iterator

I know that hashtable is thread safe, but is sure ?

One thing that I don't understand : why the application doesn't blow up if one thread doesn't see that one value has been removed from the hashtable and the thread iterates on this object ?

How can we define hashtable thread-safe if the iterator isn't ?

EDIT : But now I tell you in more specific way my problem, becasue in other way i'm not clear. Following is reported the code of my concurrentHashMap :

public ConcurrentHashMap<String,Result> Holder = new ConcurrentHashMap<String,Result>();

class Result
{
    public float goal = 0;
    public float min = 0;
    public float max = 0;
    public float seconds = 0;
    //lastaccess indicate the time of the last access of this Result
    public float lastaccess = 0;
    public boolean triggered = false;
}

Now one thread B iterates every "x" seconds the Result object and for each key stored in Holder ConcurretHashMap .

Other thread set new Result for a new key or edit the Result for an existing one.

  • I want do the operation of update the Result in atomic way, but the object inside the hashmap scares me.

  • UX thread remove all item from the Holder every x second. To do this operation I to in this way : I created an

    Object mlock = new Object();

in the thread B

 syncrhonized(mlock)
    {
       //all the thread B function. 
       // Iterate on all of the Holder item
    }

in the other thread C when it have to call Holder.clear() I have done in this way :

syncronized(mlock)
{
   Holder.clear();
}
  • Is it a correct way to prevent that thread B iterate on a Holder with the inconsistent data ?
aeroxr1
  • 1,014
  • 1
  • 14
  • 36
  • possible duplicate of [Is java.util.Hashtable thread safe?](http://stackoverflow.com/questions/7400292/is-java-util-hashtable-thread-safe) – Chackle May 15 '15 at 14:00
  • @Chackle I edited my question to explain in better way my problem. It is so little differet from other question. – aeroxr1 May 17 '15 at 09:04

1 Answers1

1

It is thread safe but in high concurrent scenarios is recommended to use ConcurrentHashMap as you can see on official documentation

Claudio Redi
  • 67,454
  • 15
  • 130
  • 155
  • Thx ! Some people say that either concurrentHashMap and hashtable aren't secure because iterators are designed to be used by only one thread at a time. I'm scared that if the ui thread removes an element the other thread doesn't see this "little" change an some problem occur to my android application., because the other thread try to access to an inexistent object in the hashtable. i hope to be clear , my english is no so good.. – aeroxr1 May 15 '15 at 14:14
  • 1
    @aeroxr1: that's correct. An itearator is not safe since is a "picture" of the contents at certain time. It won't blow up but definitively you risk to itearate over a "state" copy of the data if in the meantime items are added on a different thread. – Claudio Redi May 15 '15 at 14:25
  • And if the thread doesn't added but remove item, could be a very problem because we access to a null object ? or the second thread will access to a precedent copy of the object ? Is there a way to resolve this my issue ? ConcurrenctHashMap has the same iterator problematic, right ? – aeroxr1 May 15 '15 at 14:28
  • 1
    @aeroxr1: you'll have to analyze how important is getting "online" updates on hash table. It may be possible that in your scenario is ok to miss an update done while iterating. If not acceptable, a lock could be a valid option. – Claudio Redi May 15 '15 at 15:23
  • I have edited my first post inserting a part of my code and explaining in better way my problem (Or at least I think) – aeroxr1 May 17 '15 at 09:06