This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes Example in sample chapter Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Example in sample chapter" Watch "Example in sample chapter" New topic
Author

Example in sample chapter

David Ulicny
Ranch Hand

Joined: Aug 04, 2004
Posts: 724
Hello Henry,
I tried example from the sample chapter. It is the example about volatile varibles, but I'm not sure if I understand it well. Here is my attempt


I suppose that this should be never stopped. But it stops. No output in console.
Thanks in advance.


SCJP<br />SCWCD <br />ICSD(286)<br />MCP 70-216
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Indeed I should expect the same behavior as described, but it is not there. Hmmm... something smells .

./pope


blog - InfoQ.com
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18874
    
  40

Not sure what you are talking about, since the example you showed is not an example in the book... Unless you are talking about the example chapter, and are trying test something in it?

Assuming that you are trying to test the fact that volatile variables may be cached... the example may run forever, it may run for many iterations after you set the done flag, or it may exit immediately depending on the JVM you are using.

But... in my opinion, you probably set the done flag before you given the new thread a chance to start. Put in a delay before setting the flag, and see what happens.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18874
    
  40

Oh... I see what you did, you wrote a testing example from the 5 line code snippet.

Anyway, then I did assumed correctly... add a delay and see what happens.

Henry
jiju ka
Ranch Hand

Joined: Oct 12, 2004
Posts: 306
There are two threads involved here.
The thread started with the main method have the preference here because it is alreasdy executing.
When the line v.start is executed a new thread will wait for the current thread to finish.
Because of this the current thread sets the done flag to true. Then the current thread will terminate. Then the waiting thread v.start takes precedence. But there is no guarantee on which thread will take precedence. Only thing sure is that there is more probability of having the CPU time slot available to main thread.

Similar to giving a wait which will difinitely make the main thread wait, try the code below.


This will show the relation between input output operations and CPU time slots

The output will look like follows.

[LINK]
Run atThu Oct 28 11:31:27 CDT 2004
Foo
Run atThu Oct 28 11:31:27 CDT 2004
Foo
..
..
..
Foo
Run atThu Oct 28 11:31:27 CDT 2004
Foo
set atThu Oct 28 11:31:27 CDT 2004
Run atThu Oct 28 11:31:27 CDT 2004
Foo

[/link]

See the thread looses precedence in between print("set at.) and done = true;
This is because time slots ends after printing
set atThu Oct 28 11:31:27 CDT 2004
So the main thread loses precedence again.

The output varies with OS and CPU utilization since the time slices and precedence varies.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

It may or may not stop, that is the problem.

All threading problems have to to with indeterminate behavior. That behavior is hard to observe. Especially if your running on a single CPU machine.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Example in sample chapter