Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Problem with thread behaviour on different plattforms

 
Guilberto Cuevas
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi. I've written a test program that run a 100 instances of a very simple thread (only increment a integer). I test this program in sxde (amd64) and win xp (32bit) with the same result, however running the program in linux (mandriva 2008.1 64bit) and freebsd 7.0 (amd64) shows that only one thread do his job and the program keeps executing forever consuming a 100% cpu. Searching in the web I discover that exists a problem with Java Threads and NPTL implementation (making an strace in linux shows a FUTEX_WAIT error). I would like to know if exists a solution to this problem.
Thanks in advance.


PD: I have installed the four OS in the same machine. All OS have Sun jdk6 except for freebsd that has diablo-jdk6.
 
Guilberto Cuevas
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The test Thread:



[Nitesh: Use codetags]
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know anything about Java Threads and NPTL implementation issues however your code looks bugged to me if you intend another thread to call your setters which I presume you do ?? ...


try...



Your thread has no guarantee of visibility of any changes another thread makes eg setting work to true can still allow for ...



to fail so your thread can spin forever munching all your CPU (depending on the presence of the sleep). Solaris and Windows normally (Solaris usually TSO, Windows unless IA64) , work with strong memory models which don't exhibit this behaviour (often ??? for Windows MSDN tells you not to worry about it for none IA64 but remember they're talking C++ and your in a JVM) , Linux type OS's I think use weaker memory models (regardless the code is just bugged)

I suggest you try some volatiles or synchronized blocks first and then repost with how its behaving broke, fixed, worse whatever ...





 
Alan Mehio
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guilberto Cuevas wrote:The test Thread:



[Nitesh: Use codetags]


Having looked at the code; I think you are better off testing your code by implementing Runnable interface instead and executing it through the executorService from java.util.concurrent package
If you do so and still get the same problem, then let us know.


 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic