aspose file tools*
The moose likes Threads and Synchronization and the fly likes A bunch of questions on threads. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "A bunch of questions on threads." Watch "A bunch of questions on threads." New topic
Author

A bunch of questions on threads.

Dmitry Zhuravlev
Ranch Hand

Joined: Apr 14, 2010
Posts: 93
Gentlemen, I continue with my concurrency study and need some help with a set of concurrency issues, please.

1) Imagine we have a volatile variable which holds a reference to some object. This attributes of that variable are concurrently modified by several threads. Will all the attributes become volatile (i.e. visible to all the threads) also?
Imagine we have a local variable that is passed into several Runnable constructors and then modified in each of the Runnable by corresponding thread. How can we assure that all modifications made to that variable are visible to other threads?

2) Are HttpSession attributes getters/setters thread-safe?
I have googled several different approaches to this issue. Some people say yes, others say it is not guaranteed. The worse is that no one garantees on the instance of the mutex is used: does HttpSession really synchronizes on itself or not?

Basing on the experience of yours, would you synchronize this piece of code?


3) There are several ways to deal with tasks which result is needed after delay. Is there any significant difference between using the countDownLatch.await(TIMEOUT, units),
futures.get(TIMEOUT, units) and ExecutorService.invokeAll(tasks, TIMEOUT, units)?

4) I have a ThreadPool in my application which can be used by several threads simultaneously. It looks like



Is ExecutorService is thread-safe?
Generally how can I know whether the class from java package is thread-safe?
Do I need to place a pool.shutdown() call somewhere, when my application ends? If yes, where can I place it? I cannot use finalize() because its a non-static method and there would be no instances of MyUtilsClass.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

Dmitry Zhuravlev wrote:1) Imagine we have a volatile variable which holds a reference to some object. This attributes of that variable are concurrently modified by several threads. Will all the attributes become volatile (i.e. visible to all the threads) also?

No. Volatile applies only to the variable, not any objects it may refer to.

Imagine we have a local variable that is passed into several Runnable constructors and then modified in each of the Runnable by corresponding thread. How can we assure that all modifications made to that variable are visible to other threads?

By proper use of synchronization, or by making the object you are passing thread-safe.

2) Are HttpSession attributes getters/setters thread-safe?

HttPSession is an interface, so no. There may be subclasses that are not thread-safe.

Basing on the experience of yours, would you synchronize this piece of code?

If that piece of code can be called by several threads in your program concurrently, then yes.

3) There are several ways to deal with tasks which result is needed after delay. Is there any significant difference between using the countDownLatch.await(TIMEOUT, units),
futures.get(TIMEOUT, units) and ExecutorService.invokeAll(tasks, TIMEOUT, units)?

Yes. The documentation describes these difference. Use the method that is appropriate in your context. If you have a thread that needs to wait for something to count down, use CountDownLatch. If you have several tasks that need to be executed, and you want them to cancel after the timeout, use ExecutorService. If you simply want to wait a certain amount of time for the result of a task to become available, use Future.

4) [...] Is ExecutorService is thread-safe?
Generally how can I know whether the class from java package is thread-safe?

Again, ExecutorService is an interface, so no. There may be subclasses that are not thread-safe.
You can tell if a specific class or interface is thread-safe if their documentation says so. If the ExecutorService interface said that all implementing classes must be thread-safe, only then may you assume it's thread safe.
Usually, the last paragraph in the overview of a class will say how it behaves in regards to concurrency. Sadly, they didn't document this in the ExecutorService interface, nor in the ThreadPoolExecutor class. I would assume however, that something as an ExecutorService would be safe for use by multiple threads. This is a dangerous assumption though.

Do I need to place a pool.shutdown() call somewhere, when my application ends? If yes, where can I place it? I cannot use finalize() because its a non-static method and there would be no instances of MyUtilsClass.

When your program ends? No, you don't have to. When your program ends, it ends, and all resources are reclaimed automatically. When you're done using an ExecutorService and your program isn't sure to end right afterwards, shut it down.

Usually it's good practice to shut it down in a try-finally block, regardless.
Dmitry Zhuravlev
Ranch Hand

Joined: Apr 14, 2010
Posts: 93
Stephan, thanks!

One more question arrived.

Are ServletContext attributes volatile?

Imagine one user on a web-site changes ServletContext attribute via submitting some data to Servlet or Filter Controller. Do I need some extra coding to be sure that the commited modification is visible to all the users online and all threads in my application?
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

What did the documentation say?
Dmitry Zhuravlev
Ranch Hand

Joined: Apr 14, 2010
Posts: 93
Stephan,
it says nothing on this.

May be thats because ServletContext is an interface.

I have found a source of Apache Tomcat ApplicationContext which implements the ServletContext. Here is the link: http://www.docjar.com/html/api/org/apache/catalina/core/ApplicationContext.java.html

As far as I see from that file all the attributes are stored inside ConcurrentHashMaps, so operations on them should be considered thread-safe.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

You may not assume this. If the documentation of their class doesn't say it's thread safe, then you shouldn't treat it as such, even if its implementation may be.

Even if you have a thread-safe implementation of ServletContext, as long as you're using a reference of type ServletContext and not the thread-safe subtype, you may not assume it's thread-safe; unless your code can guarantee the ServletContext reference always points to a thread-safe instance.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: A bunch of questions on threads.