wood burning stoves 2.0*
The moose likes Threads and Synchronization and the fly likes BigInteger & Multithreading Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "BigInteger & Multithreading" Watch "BigInteger & Multithreading" New topic
Author

BigInteger & Multithreading

James Stonert
Greenhorn

Joined: Dec 22, 2005
Posts: 4
Hi everybody,

First, sorry if my english is not very good, I come from Belgium ;-).

I have a little question about the BigInteger (package java.math) class. By having a glance at its source, we can see that it is fully immutable.

Recently, I discovered that a bug was reported concerning this class at the following URL http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6348370.
The guy talks about the fact that it is possible to modify an object that had been instanciated in one Thread before (through its reference).

As I am interested in this class behaviour, I would like to know if someone was able to reproduce this bug because I was not. I tried to instanciate several Threads and passing them a BigInteger reference but nothing append.

Thanks !!!

James.


Edit : Sorry for my name I forgot to change it after having seen the rules. Now it is done :-)
[ December 22, 2005: Message edited by: James Stonert ]
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42944
    
  68
Hello James-

Welcome to JavaRanch.

I glanced at the bug report, and it doesn't say how a BigInteger is supposed to be changed. As you point out, by their public API they're immutable. It's possible to change the fields the value is based on by using the reflection API, but I wouldn't say that that makes them thread-unsafe. And even final fields would not be safe from that.

But the bug was filed against a development version of Java 1.6, so I don't know what might be different in that compared to current production versions.
James Stonert
Greenhorn

Joined: Dec 22, 2005
Posts: 4
Thanks for your answer,

Can an object be interrupted during the call to its constructor ? IT would mean that one object that has been interrupted during the assignment to its final fields can be passed to one other Thread which will complete the assignment at its manner ?

It is the only weakness I see in this class.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18991
    
    8

Not usually. The only way in which some other thread could get a reference to an object whose constructor is still running, is if that constructor explicitly passes a reference to "this" to some other object. Example:But that isn't what that bug report says anyway. It is talking about different threads seeing a single instance differently because of the "Java memory model". If you want to know what that is all about, read chapter 17 of the Java Language Specification for yourself. It's certainly beyond my ability to explain that sort of thing. But on the other hand if you have real work to do, I would not worry about it too much.
James Stonert
Greenhorn

Joined: Dec 22, 2005
Posts: 4
Thanks Paul,

I think that the bug can be reproduced by creating an object which encapsulates a BigInteger and instanciate this into its constructor. The Java Memory Model deals with the writing of final fields and their consequence.

It deals with the fact you were talking about, and I think that the bug is relative to the example shown at page 608 from the JLS.

I keep on testing this and will post in my topic later ;-)
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18991
    
    8

Well, if you do produce bug-like behaviour then you should post the information on the bug database. What I saw there was just theoretical and didn't actually say the bug had ever occurred anywhere, so you would be providing useful information to them.
James Stonert
Greenhorn

Joined: Dec 22, 2005
Posts: 4
It seems that the problem comes from the fields used by a BigInteger to store differents values to avoid re-computing at each time.

I think it is a waste of time to try to reproduce the bug, because of the random and the rarity of Thread-based bugs.

Fields used to store some values cannot be set final, because they are assigned dynamically. So the first thing to do is certainly to synchronize all the methods that access to these fields.

Then, some fields are declared with the package visibility because they are used in other classes like BigDecimal for example. These fields cannot be set private to avoid modifying other implementations, but I think we need to synchronize the methods which write these fields too.

In conclusion, I think that the problem can be resumed into a synchronization from some methods of the class, and put a private modifier where we can.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: BigInteger & Multithreading