Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...
Java Forum / General / February 2007

Tip: Looking for answers? Try searching our database.

Two more multithreading questions

Thread view: 
Enable EMail AlertsStart New Thread
Knute Johnson - 30 Jan 2007 03:53 GMT
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,

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message
hiwa - 30 Jan 2007 09:59 GMT
On Jan 30, 12:53 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:
> I've got two specific scenarios I want to ask about:
>
[quoted text clipped - 18 lines]
> 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 to this Message
Patricia Shanahan - 30 Jan 2007 13:36 GMT
> I've got two specific scenarios I want to ask about:
>
[quoted text clipped - 6 lines]
> 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 to this Message
Knute Johnson - 30 Jan 2007 17:44 GMT
>> I've got two specific scenarios I want to ask about:
>>
[quoted text clipped - 10 lines]
> 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,

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message
Daniel Pitts - 30 Jan 2007 18:35 GMT
On Jan 30, 9:44 am, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:
> >> I've got two specific scenarios I want to ask about:
>
[quoted text clipped - 20 lines]
> 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/api/java/util/concurrent/package-
summary.html>

Good luck :-)
Reply to this Message
Knute Johnson - 30 Jan 2007 18:55 GMT
> On Jan 30, 9:44 am, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
> wrote:
[quoted text clipped - 53 lines]
>
> 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,

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message
Daniel Pitts - 30 Jan 2007 21:54 GMT
On Jan 30, 10:55 am, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:
> > On Jan 30, 9:44 am, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
> > wrote:
[quoted text clipped - 75 lines]
> 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/api/java/util/concurrent/package-
summary.html>

Hope this answers your question a little better.
Reply to this Message
A. Bolmarcich - 30 Jan 2007 22:30 GMT
> 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
[quoted text clipped - 5 lines]
> 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 to this Message
Knute Johnson - 31 Jan 2007 00:59 GMT
>> 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
[quoted text clipped - 20 lines]
> 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,

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message
A. Bolmarcich - 31 Jan 2007 16:48 GMT
> This is why I keep asking these questions because I get different
> answers.  Can you explain what is meant in the documentation then by:
[quoted text clipped - 4 lines]
> 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 to this Message
Knute Johnson - 31 Jan 2007 17:47 GMT
>> This is why I keep asking these questions because I get different
>> answers.  Can you explain what is meant in the documentation then by:
[quoted text clipped - 27 lines]
> consider to be the most recent write to be done before the read, the
> answer is no.

Thanks very much for your response.  The two actions are independent and
I do not want to effect when they occur.  I just want to ensure that if
an assignment is made to the variable that any subsequent read in the
other thread will have the latest value.

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message
A. Bolmarcich - 31 Jan 2007 19:40 GMT
> Thanks very much for your response.  The two actions are independent and
> I do not want to effect when they occur.  I just want to ensure that if
> an assignment is made to the variable that any subsequent read in the
> other thread will have the latest value.

Without any other sychronization action between the threads, the only
way you know that a read was subsequent to a write is based on the value
that was read.  A read is subsequent to a write that wrote the value
that was read.

The fact that the variable is volatile means that reads and writes by
a thread cannot be reordered to be before the previous synchronization
action or after the next synchronization action.  According to section
"8.3.1.4 volatile Fields" of the JLS (from
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
given the class

 class Test {
   static volatile int i = 0, j = 0;
   static void one() { i++; j++; }
   static void two() {
     System.out.println("i=" + i + " j=" + j);
   }
 }

If method one() is repeatedly called by one thread and method two() is
repeatedly called by another thread, then according to the JLS:

 Therefore, the shared value for j is never greater than that for i,
 because each update to i must be reflected in the shared value for i
 before the update to j occurs.

If the variables i and j were not volatile, then lines printed by method
two() may have a value of j greater than that of i.
Reply to this Message
Knute Johnson - 31 Jan 2007 21:23 GMT
>> Thanks very much for your response.  The two actions are independent and
>> I do not want to effect when they occur.  I just want to ensure that if
[quoted text clipped - 30 lines]
> If the variables i and j were not volatile, then lines printed by method
> two() may have a value of j greater than that of i.

So that's a yes?

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message
A. Bolmarcich - 01 Feb 2007 00:20 GMT
>>> Thanks very much for your response.  The two actions are independent and
>>> I do not want to effect when they occur.  I just want to ensure that if
[quoted text clipped - 32 lines]
>
> So that's a yes?

Like many questions about the interaction of multiple threads, the
question does not have a simple "yes" or "no" answer.  The best that I
can respond is to repeat: a read is subsequent to a write that wrote the
value that was read.  If that is what you mean by "subsequent read" in
your qestion, the answer is "yes".
Reply to this Message
Knute Johnson - 01 Feb 2007 02:30 GMT
>>>> Thanks very much for your response.  The two actions are independent and
>>>> I do not want to effect when they occur.  I just want to ensure that if
[quoted text clipped - 36 lines]
> value that was read.  If that is what you mean by "subsequent read" in
> your qestion, the answer is "yes".

I have no idea what that means.  By subsequent I mean the usual meaning
that the subsequent action occurs later in time than the precedent
action.  So in the case I am asking about, the first thread writes to
the variable and then some time later the second thread reads the variable.

Does volatile guarantee that the second thread will see the value
written by the first thread?

Does synchronizing guarantee that the second thread will see the value
written by the first thread?

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message
A. Bolmarcich - 01 Feb 2007 18:41 GMT
>> Like many questions about the interaction of multiple threads, the
>> question does not have a simple "yes" or "no" answer.  The best that I
[quoted text clipped - 12 lines]
> Does synchronizing guarantee that the second thread will see the value
> written by the first thread?

When "the first thread writes to the variable" a processor requests that
a value be written to a memory address.  On some computers the request
goes into a queue and the effect of the memory write is visible to other
threads sometime later.  While the memory write is being done, the first
thread continues executing.
                                                                               
On this type of computer architecture, whether a memory read is subsequent
to a memory write depends on the whether the read gets the value written
by the memory write.  It does not depend on the global order in which
threads execute instructions.
                                                                               
The answer to your question: "Does volatile guarantee that the second
thread will see the value written by the first thread?", is yes, as long
as you take "some time later" being in terms of what is visible in memory
and not in terms of the global order in which the threads execute the
instruction.
                                                                               
The answer to your question: "Does synchronizing guarantee that the
second thread will see the value written by the first thread?" is yes,
with "some time later" being in terms of the second thread entering its
synchronized block after the first thread exited its synchronized block.
Reply to this Message
Knute Johnson - 01 Feb 2007 22:39 GMT
>>> Like many questions about the interaction of multiple threads, the
>>> question does not have a simple "yes" or "no" answer.  The best that I
[quoted text clipped - 33 lines]
> with "some time later" being in terms of the second thread entering its
> synchronized block after the first thread exited its synchronized block.

Thanks very much.  I appreciate the time and effort.

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message
Daniel Pitts - 31 Jan 2007 22:23 GMT
On Jan 31, 11:40 am, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
wrote:

> > Thanks very much for your response.  The two actions are independent and
> > I do not want to effect when they occur.  I just want to ensure that if
[quoted text clipped - 29 lines]
> If the variables i and j were not volatile, then lines printed by method
> two() may have a value of j greater than that of i.
Actually, they still might.
imagine this scenario:

Thread 2: two gets called
Thread 2: value i is loaded and converted to a string for
concatication
Thread 1: one gets called
Thread 1: one gets called again
Thread 1: one gets called a third time
Thread 2: continues with j

Output is i=0 j=3

Also possible is:
Thread 1: one gets called
Thread 1: increments i
Thread 2: one gets called
Thread 2: increments i
Thread 3: two gets called
Thread 3: output i=2 j=0
Thread1: increments j
Thread2: increments j

A even worse possibility:
Thread 1: reads value of i
Thread 2: reads value of i
Thread 1: writes value of i+1 back to i
Thread 2: writes values of i+1 back to i
Thread 1: increments j
Thread 2: increments j
Thread 3: wait for thread1 and thread2
Thread 3: call two
Output i=1 j=2
Reply to this Message
A. Bolmarcich - 01 Feb 2007 00:24 GMT
> On Jan 31, 11:40 am, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
> wrote:
[quoted text clipped - 44 lines]
>
> Output is i=0 j=3

Which is a case of the value of j being greater than that of i that I wrote
may occur.

> Also possible is:
> Thread 1: one gets called
[quoted text clipped - 5 lines]
> Thread1: increments j
> Thread2: increments j

In the extract of the JLS section, there are only two threads: one invokes
one() and the other invokes two().

> A even worse possibility:
> Thread 1: reads value of i
[quoted text clipped - 6 lines]
> Thread 3: call two
> Output i=1 j=2

In the extract of the JLS section, there are only two threads: one invokes
one() and the other invokes two().
Reply to this Message
Daniel Pitts - 01 Feb 2007 01:22 GMT
On Jan 31, 4:24 pm, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
wrote:
> > On Jan 31, 11:40 am, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
> > wrote:
[snip]
> >> The fact that the variable is volatile means that reads and writes by
> >> a thread cannot be reordered to be before the previous synchronization
[quoted text clipped - 34 lines]
> Which is a case of the value of j being greater than that of i that I wrote
> may occur.
You wrote:
> If the variables i and j were not volatile, then lines printed by method
> two() may have a value of j greater than that of i.

My example is allowing them to be volatile.
Actually, my example is valid for both volatile and non-volatile
variables.

With two threads repeatedly calling their respective methods, you can
get a situation with i > j or j > i, regardless of the volatility of
the variables.

Therefore, your post doesn't explain volatile at all.
Reply to this Message
A. Bolmarcich - 01 Feb 2007 18:52 GMT
> On Jan 31, 4:24 pm, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
> wrote:
[snip]
>> > imagine this scenario:
>>
[quoted text clipped - 21 lines]
> get a situation with i > j or j > i, regardless of the volatility of
> the variables.

Sorry, I did not read your scenario carefully enough.  Yes, when
i and j are volatile, if two() reads the value of i and one() is invoked
again before two() reads the value of j, then two() may print j value
that is greater than the i value.
Reply to this Message


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage
Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.