Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Two more multithreading questions

Reply
Thread Tools

Two more multithreading questions

 
 
Knute Johnson
Guest
Posts: n/a
 
      01-30-2007
I've got two specific scenarios I want to ask about:

1) I have a class with an instance variable that is a reference to a
JDialog. In one thread I create new instances of JDialog and make them
visible. They might get closed in this thread as well. In another
thread I close the JDialog using the class instance variable. To ensure
that my dialog closing thread always has a reference to the current
dialog I created the instance variable with volatile. Is this adequate
to guarantee that my closing thread always has a reference to the latest
dialog?

2) If I want to access/modify an Object in two threads, can I use a
reference to any Object in the synchronize statement to do that? It
doesn't have to be the reference to the Object that I am trying to
protect as long as the accesses are all in synchronized blocks?

Thanks very much,

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
 
 
 
hiwa
Guest
Posts: n/a
 
      01-30-2007
On Jan 30, 12:53 pm, Knute Johnson <(E-Mail Removed)>
wrote:
> I've got two specific scenarios I want to ask about:
>
> 1) I have a class with an instance variable that is a reference to a
> JDialog. In one thread I create new instances of JDialog and make them
> visible. They might get closed in this thread as well. In another
> thread I close the JDialog using the class instance variable. To ensure
> that my dialog closing thread always has a reference to the current
> dialog I created the instance variable with volatile. Is this adequate
> to guarantee that my closing thread always has a reference to the latest
> dialog?
>
> 2) If I want to access/modify an Object in two threads, can I use a
> reference to any Object in the synchronize statement to do that? It
> doesn't have to be the reference to the Object that I am trying to
> protect as long as the accesses are all in synchronized blocks?
>
> Thanks very much,
>
> --
>
> Knute Johnson
> email s/nospam/knute/


Q 1) may need some code for me to understand.
For Q 2), if you mean
synchronized(obj){...} construct,
'obj' can be anything. The 'obj' is not protected
by this construct.


 
Reply With Quote
 
 
 
 
Patricia Shanahan
Guest
Posts: n/a
 
      01-30-2007
Knute Johnson wrote:
> I've got two specific scenarios I want to ask about:
>
> 1) I have a class with an instance variable that is a reference to a
> JDialog. In one thread I create new instances of JDialog and make them
> visible. They might get closed in this thread as well. In another
> thread I close the JDialog using the class instance variable. To ensure
> that my dialog closing thread always has a reference to the current
> dialog I created the instance variable with volatile. Is this adequate
> to guarantee that my closing thread always has a reference to the latest
> dialog?


I believe most javax.swing component access is supposed to be done in
the event handling thread anyway. Swing was not designed to be
multithread-safe.

> 2) If I want to access/modify an Object in two threads, can I use a
> reference to any Object in the synchronize statement to do that? It
> doesn't have to be the reference to the Object that I am trying to
> protect as long as the accesses are all in synchronized blocks?


Two threads can be in synchronized blocks at the same time, as long as
they are synchronized on different objects. You don't have to use the
object you are protecting, but all accesses to that object must be
synchronized on the same lock object.

Patricia
 
Reply With Quote
 
Knute Johnson
Guest
Posts: n/a
 
      01-30-2007
Patricia Shanahan wrote:
> Knute Johnson wrote:
>> I've got two specific scenarios I want to ask about:
>>
>> 1) I have a class with an instance variable that is a reference to a
>> JDialog. In one thread I create new instances of JDialog and make
>> them visible. They might get closed in this thread as well. In
>> another thread I close the JDialog using the class instance variable.
>> To ensure that my dialog closing thread always has a reference to the
>> current dialog I created the instance variable with volatile. Is this
>> adequate to guarantee that my closing thread always has a reference to
>> the latest dialog?

>
> I believe most javax.swing component access is supposed to be done in
> the event handling thread anyway. Swing was not designed to be
> multithread-safe.
>


Sorry, bad example. Say it is an Integer that is being created in one
thread and in the other you are using the intValue() method.

Thanks,

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      01-30-2007
On Jan 30, 9:44 am, Knute Johnson <(E-Mail Removed)>
wrote:
> Patricia Shanahan wrote:
> > Knute Johnson wrote:
> >> I've got two specific scenarios I want to ask about:

>
> >> 1) I have a class with an instance variable that is a reference to a
> >> JDialog. In one thread I create new instances of JDialog and make
> >> them visible. They might get closed in this thread as well. In
> >> another thread I close the JDialog using the class instance variable.
> >> To ensure that my dialog closing thread always has a reference to the
> >> current dialog I created the instance variable with volatile. Is this
> >> adequate to guarantee that my closing thread always has a reference to
> >> the latest dialog?

>
> > I believe most javax.swing component access is supposed to be done in
> > the event handling thread anyway. Swing was not designed to be
> > multithread-safe.

>
> Sorry, bad example. Say it is an Integer that is being created in one
> thread and in the other you are using the intValue() method.
>
> Thanks,
>
> --
>
> Knute Johnson
> email s/nospam/knute/



Integer is a bad example too, since it is immutable, which means onces
its created, its value doesn't change.
A good example might be a File object.

Thread W can alter the file object, and Thread R can query it.
The safest way to insure that your Thread R only sees what its
supposed to is to wrap bother the object modifying and object querying
code in synchronize blocks that sync on the same object O. That
object O can be ANY object.

public class ThreadSafeFileAccessor {
private final Object sync = new Object();
private File file = new File();
public void modifyFile() {
synchronize(sync) {
// do modification of file
}
}

public String queryFile() {
synchronize(sync) {
return file.toString();
}
}
}

Also be aware that Java 1.5 includes a new locking mechanism and other
concurrency utilities which gives you more fine grained control over
thread synchronization.
<http://java.sun.com/j2se/1.5.0/docs/...rrent/package-
summary.html>

Good luck

 
Reply With Quote
 
Knute Johnson
Guest
Posts: n/a
 
      01-30-2007
Daniel Pitts wrote:
> On Jan 30, 9:44 am, Knute Johnson <(E-Mail Removed)>
> wrote:
>> Patricia Shanahan wrote:
>>> Knute Johnson wrote:
>>>> I've got two specific scenarios I want to ask about:
>>>> 1) I have a class with an instance variable that is a reference to a
>>>> JDialog. In one thread I create new instances of JDialog and make
>>>> them visible. They might get closed in this thread as well. In
>>>> another thread I close the JDialog using the class instance variable.
>>>> To ensure that my dialog closing thread always has a reference to the
>>>> current dialog I created the instance variable with volatile. Is this
>>>> adequate to guarantee that my closing thread always has a reference to
>>>> the latest dialog?
>>> I believe most javax.swing component access is supposed to be done in
>>> the event handling thread anyway. Swing was not designed to be
>>> multithread-safe.

>> Sorry, bad example. Say it is an Integer that is being created in one
>> thread and in the other you are using the intValue() method.
>>
>> Thanks,
>>
>> --
>>
>> Knute Johnson
>> email s/nospam/knute/

>
>
> Integer is a bad example too, since it is immutable, which means onces
> its created, its value doesn't change.
> A good example might be a File object.
>
> Thread W can alter the file object, and Thread R can query it.
> The safest way to insure that your Thread R only sees what its
> supposed to is to wrap bother the object modifying and object querying
> code in synchronize blocks that sync on the same object O. That
> object O can be ANY object.
>
> public class ThreadSafeFileAccessor {
> private final Object sync = new Object();
> private File file = new File();
> public void modifyFile() {
> synchronize(sync) {
> // do modification of file
> }
> }
>
> public String queryFile() {
> synchronize(sync) {
> return file.toString();
> }
> }
> }
>
> Also be aware that Java 1.5 includes a new locking mechanism and other
> concurrency utilities which gives you more fine grained control over
> thread synchronization.
> <http://java.sun.com/j2se/1.5.0/docs/...rrent/package-
> summary.html>
>
> Good luck
>


Daniel:

Thank you very much for your response but it doesn't really answer my
question. As to the immutable, I'm not muting. So let me set the
scenario again.

Class with instance variable that is reference to Integer. One thread
makes new Integers and assigns them to the instance variable. The other
thread calls some method on the Integer. I want to know if making the
variable volatile will guarantee that the second thread always sees the
latest integer created by the first thread.

I know that I can wrap both pieces of code in a synchronized block but I
want to understand my question.

Thanks very much,

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      01-30-2007
On Jan 30, 10:55 am, Knute Johnson <(E-Mail Removed)>
wrote:
> Daniel Pitts wrote:
> > On Jan 30, 9:44 am, Knute Johnson <(E-Mail Removed)>
> > wrote:
> >> Patricia Shanahan wrote:
> >>> Knute Johnson wrote:
> >>>> I've got two specific scenarios I want to ask about:
> >>>> 1) I have a class with an instance variable that is a reference to a
> >>>> JDialog. In one thread I create new instances of JDialog and make
> >>>> them visible. They might get closed in this thread as well. In
> >>>> another thread I close the JDialog using the class instance variable.
> >>>> To ensure that my dialog closing thread always has a reference to the
> >>>> current dialog I created the instance variable with volatile. Is this
> >>>> adequate to guarantee that my closing thread always has a reference to
> >>>> the latest dialog?
> >>> I believe most javax.swing component access is supposed to be done in
> >>> the event handling thread anyway. Swing was not designed to be
> >>> multithread-safe.
> >> Sorry, bad example. Say it is an Integer that is being created in one
> >> thread and in the other you are using the intValue() method.

>
> >> Thanks,

>
> >> --

>
> >> Knute Johnson
> >> email s/nospam/knute/

>
> > Integer is a bad example too, since it is immutable, which means onces
> > its created, its value doesn't change.
> > A good example might be a File object.

>
> > Thread W can alter the file object, and Thread R can query it.
> > The safest way to insure that your Thread R only sees what its
> > supposed to is to wrap bother the object modifying and object querying
> > code in synchronize blocks that sync on the same object O. That
> > object O can be ANY object.

>
> > public class ThreadSafeFileAccessor {
> > private final Object sync = new Object();
> > private File file = new File();
> > public void modifyFile() {
> > synchronize(sync) {
> > // do modification of file
> > }
> > }

>
> > public String queryFile() {
> > synchronize(sync) {
> > return file.toString();
> > }
> > }
> > }

>
> > Also be aware that Java 1.5 includes a new locking mechanism and other
> > concurrency utilities which gives you more fine grained control over
> > thread synchronization.
> > <http://java.sun.com/j2se/1.5.0/docs/...rrent/package-
> > summary.html>

>
> > Good luck

>
> Daniel:
>
> Thank you very much for your response but it doesn't really answer my
> question. As to the immutable, I'm not muting. So let me set the
> scenario again.
>
> Class with instance variable that is reference to Integer. One thread
> makes new Integers and assigns them to the instance variable. The other
> thread calls some method on the Integer. I want to know if making the
> variable volatile will guarantee that the second thread always sees the
> latest integer created by the first thread.
>
> I know that I can wrap both pieces of code in a synchronized block but I
> want to understand my question.
>
> Thanks very much,
>
> --
>
> Knute Johnson
> email s/nospam/knute/



Ah, you didn't ask about volatile before. Yes, volatile is supposed
to make it so that one thread can see the primative data written by
another in a thread safe manor. A reference to an object is a
primative for this argument.

So, if all you care about is the reference, then you don't need
synchronization. Although, you still might be better off looking into
java.util.concurrent.AtomicInteger or
java.util.concurrent.AtomicReference
<http://java.sun.com/j2se/1.5.0/docs/...rrent/package-
summary.html>

Hope this answers your question a little better.

 
Reply With Quote
 
A. Bolmarcich
Guest
Posts: n/a
 
      01-30-2007
On 2007-01-30, Knute Johnson <(E-Mail Removed)> wrote:
> Thank you very much for your response but it doesn't really answer my
> question. As to the immutable, I'm not muting. So let me set the
> scenario again.
>
> Class with instance variable that is reference to Integer. One thread
> makes new Integers and assigns them to the instance variable. The other
> thread calls some method on the Integer. I want to know if making the
> variable volatile will guarantee that the second thread always sees the
> latest integer created by the first thread.


No, volatile does not "guarantee that the second thread always sees the
latest integer created by the first thread". What volatile guarantees
is that when one thread executes assignment statements to volatile
variables other threads will see the effect of the assignment
statements in the same order that they were executed.

It is possible that one thread starts executing an assignment statement
to a volatile variable and very slightly later another thread starts
executing a statement that uses the value of that variable. The second
thread may get the value of the variable before latest assignment
statment by the first thread. A basic problem is that without some
form of synchronization between theads (not necessarily by the Java
synchronize statement) there is no definite time ordering of operations
between threads.
 
Reply With Quote
 
Knute Johnson
Guest
Posts: n/a
 
      01-31-2007
A. Bolmarcich wrote:
> On 2007-01-30, Knute Johnson <(E-Mail Removed)> wrote:
>> Thank you very much for your response but it doesn't really answer my
>> question. As to the immutable, I'm not muting. So let me set the
>> scenario again.
>>
>> Class with instance variable that is reference to Integer. One thread
>> makes new Integers and assigns them to the instance variable. The other
>> thread calls some method on the Integer. I want to know if making the
>> variable volatile will guarantee that the second thread always sees the
>> latest integer created by the first thread.

>
> No, volatile does not "guarantee that the second thread always sees the
> latest integer created by the first thread". What volatile guarantees
> is that when one thread executes assignment statements to volatile
> variables other threads will see the effect of the assignment
> statements in the same order that they were executed.
>
> It is possible that one thread starts executing an assignment statement
> to a volatile variable and very slightly later another thread starts
> executing a statement that uses the value of that variable. The second
> thread may get the value of the variable before latest assignment
> statment by the first thread. A basic problem is that without some
> form of synchronization between theads (not necessarily by the Java
> synchronize statement) there is no definite time ordering of operations
> between threads.


This is why I keep asking these questions because I get different
answers. Can you explain what is meant in the documentation then by:

JLS 17.4.4 Synchronization Order
....
A write to a volatile variable (8.3.1.4) v synchronizes-with all
subsequent reads of v by any thread (where subsequent is defined
according to the synchronization order).

Thanks very much,

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
A. Bolmarcich
Guest
Posts: n/a
 
      01-31-2007
On 2007-01-31, Knute Johnson <(E-Mail Removed)> wrote:
> This is why I keep asking these questions because I get different
> answers. Can you explain what is meant in the documentation then by:
>
> JLS 17.4.4 Synchronization Order
> ...
> A write to a volatile variable (8.3.1.4) v synchronizes-with all
> subsequent reads of v by any thread (where subsequent is defined
> according to the synchronization order).


Note that "subsequent is defined according to the synchronization order".
Earlier in the section synchronization order is defined of an execution.
Different executions may have different synchronization orders.

According to the section 17.4.5 Happens-before Order: "It should be noted
that the presence of a happens-before relationship between two actions
does not necessarily imply that they have to take place in that order in
an implementation. If the reordering produces results consistent with a
legal execution, it is not illegal."

If there is nothing that forces the ordering of an execution to be that
the write action is before the read, then the read may occur before the
write.

Your previous question was: "I want to know if making the variable
volatile will guarantee that the second thread always sees the latest
integer created by the first thread." The answer depends on exactly
what you mean by "latest". The second thread will always see the most
recent write action by the first thread that has completed. However,
unless you have another synchronization action to force what you
consider to be the most recent write to be done before the read, the
answer is no.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Two more questions Frank Winkler Cisco 0 02-19-2008 10:26 AM
How to compare two SOAP Envelope or two Document or two XML files GenxLogic Java 3 12-06-2006 08:41 PM
Kamaelia 0.4.0 RELEASED - Faster! More Tools! More Examples! More Docs! ;-) Michael Python 4 06-26-2006 08:00 AM
Two more questions chlori HTML 6 01-21-2005 12:04 PM
substitute two ore more with two or more Robert Wallace Perl Misc 1 12-31-2003 05:13 PM



Advertisments