Only 48 hours left in the trailboss' kickstarter!

New rewards and stretch goals. CLICK HERE!



  • Post Reply Bookmark Topic Watch Topic
  • New Topic

A couple of threaded questions  RSS feed

 
Tom Diamond
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
Here is my problem:
I have a Hashtable field which is accessed by multiple threads. Hashtable is synchronized according to the API. This means that I can access it as is without worrying about synchronization?
Does it make any difference if the field is static or not? If not static should getters and setters be synchronized or not?
Tnx in advance,
Tom.
 
Liu Fei
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi~
I write down my understanding about the problem. May not be correct.
1. Yes. Hashtable can be accessed without worrying about synchronization.
2. There is a lock for a class, when static field or method need be synchronized. Class lock is different from object lock. For example, class AB has two instances a and b, a synchronized method instanceMethod(), and a static synchronized method classMethod().
When instance 'a' enters the instanceMethod(), 'b' can also enter the method even if they are in two threads. But if two threads access classMethod(), they will be synchronized.
3. Yes. Since the class is under multi-thread, in general, getters and setters should be synchronized.
Originally posted by Tom Diamond:
Hello,
Here is my problem:
I have a Hashtable field which is accessed by multiple threads. Hashtable is synchronized according to the API. This means that I can access it as is without worrying about synchronization?
Does it make any difference if the field is static or not? If not static should getters and setters be synchronized or not?
Tnx in advance,
Tom.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a Hashtable field which is accessed by multiple threads. Hashtable is synchronized according to the API. This means that I can access it as is without worrying about synchronization?
Sometimes - it depends what you're trying to do. One of the worst things about Hashtable and Vector is that people think anything they do with them is going to be thread-safe. That's not always the case. Individual methods of the class(es) are thread-safe, but often you need synchronization at a higher level. E.g. in something like this:

Here the individual get() and put() calls are synchonized. But if more than one thread can call getFooFor(), then there may still be problems. Consider:
  • Thread A does get("myfoo"), which is null.
  • Thread B does get("myfoo"), which is null.
  • Thread A creates a new Foo, puts it in the Hashtable, and returns the new Foo.
  • Thread B creates a new Foo, puts it in the Hashtable (replacing the one A created), and returns the new Foo.

  • So now B's new Foo() has replaced the one A created - but A is still using the first one. Is this OK? Well it depends - the Foo class may have been written with the assumption that there would be only one Foo for a given key, and now there are two. Perhaps each Foo will try to open a log file titled myfoo.txt, and the second Foo will fail because there's a FileWriter in the first Foo which is holding a lock on the newly created file. If something like that is going on, then the getFooFor() method really needs to prevent accidentally creating two Foos for the same key. And to do that, the method needs to be synchronized so that Thread B won't be able to do a get() until after Thread A has done its put(). This may seem a contrived example, but it's not too unusual to find processing done on a Hashtable which requires that other threads not interfere in between two separate Hashtable method calls. For this reason, it's dangerous to think of Hashtable as automatically thread-safe. You need to consider just what level of synchronization is really necessary for whatever problem you're trying to solve.
    Does it make any difference if the field is static or not? If not static should getters and setters be synchronized or not?
    First: Getters and setters? You mean like these?
    public Hashtable getHashtable()
    public void setHashtable(Hashtable ht)
    If the Hashtable reference itself is being changed (by set) rather than merely changing data inside the Hashtable, then the fact that Hashtable is "synchonized" is completely irrelevant. Here you're not using methods inside the Hashtable class, which would be synchronized, youre using methods outside the class, which aren't. So the decision as to whether or not you need to synchronize has nothing to do with the Hashtable class.
    So what does it depend on? The important question is, is the data mutable, and can more than one thread access that data? If we're talking about a mutable instance field, then the question is - can more than one thread access a single instance of your class? If so, then you need to synchronize. If the field is static, then the question is broader - can more than one thred access your class at all? Again, if the answer is yes, you must synchronize - on the class. Meaning use a static synchronized method rather than an instance method. So the answer depends in part on whether a field is static, but you also need to consider whether multiple threads have access or not. Many, many things in Java are not synchronized, and it's OK as long as you don't hand those things off to more than one thread. So thread safety generally certers around understanding what your threads might be doing, and what variables they have access to. And limiting access wherever possible so that you have fewer thening to worry about.
    Note - when I say "you must synchronize" - well, there are cases where you can get away with not synchonizing, e.g. in some cases you can use volatile instead, or you can decide that it's OK if sometimes you read invalid data, in order to increase performance. However you really shouldn't do this sort of thing unless you have a good understanding of how everyting works, and what the risks are. If you are at all uncertain about whether or not you should be synchronizing, chances are, you need to synchronize on something.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!