On Oct 14, 2007, at 4:37 AM, Eduard de
Jong wrote:
Mike,
your approach looks like an example of the general strategy to work
with immutable, value, objects.
1-- all values are represented by immutable objects
2-- Operations are specified by Mutator objects which do NOT represent
a value.
Thanks again for the reply.
This does appear to be the BigInteger strategy. I would still be
interested in some reading related to the considerations for this
strategy.
The separation between values and
operations is essential to make use of the values inherently thread
safe. I think that is a compelling reason to follow these design
principles.
In some cases this could very well be compelling. Also would just be
that BigInteger has had some smart people spend some time figuring out
how to do some fairly complicated things with very large numbers. The
convenience of this being done for you is a pretty compelling reason
itself to use it.
Since ALL Java programs are inherently multi-threaded (think
Timer, AWT, SWING), it is an imperative to make any class thread
safe.
However, just as the java collection
classes started out thread safe synchronized, performance was enough
of a concern that later on not synchronized access classes were
provided.
The problem with the first version of the collection classes was
that the critical sections of code, being protected by the inherent
lock on the collection object were too large to be efficient in
collections of practical size. This was a known issue. The basic
principle adhered too in this original design is to write a correct
program before you write a fast program, and a non thread-safe program
is NOT A CORRECT program, as it may fail at any time.
The later versions of the collection framework put the burden of
thread-safety (== program correctness) fully on the shoulders of the
programmer. The framework refactoring with distinct interfaces and
implementation classes was a way to support this. With the
introduction of fine-grained synchronization primitives in 1.6 a
couple of thread-safe collection implementations have been
added.
I still have basically only one good
example that I think pretty well demonstrates what I am talking
about.
<deleted large code examples>
The first implementation is very clear in structure so is good to
reason about its correctness, both algorithmic and thread-safety. Good
as reference implementation in a junit test!!
However, this method, being public, is incorrect in that it
allows the representation of the result, a byte[] to escape. On the
other hand if it had been a private method, where its result remains
accessible only from inside the class it would have been OK.
For instance if could have been the private conversion
constructor 'work horse; for a class Wnaf of big integers in wNAF
representation. As an aside, in that form the final array copy could
also have been left out.
As your implementation shows, the use of a byte[] instead of a
BigInt as a local variable is more efficient. As a local variable,
that can't be accessed from any other thread, there is no
thread-safety requirement.
The crucial thing, your code doesn't show, is to wrap your result
in an immutable value object. That is,however, only needed if you
intend to pass it on to other classes. As BigInt is specified only for
two complements representation, you can't use them for your result.
You need too define your own class.
<snip>
For thread concerns a synchronized could
be added somewhere - but performance concerns for that versus
immutable I have no measurements for.
Not knowing the full context of your program, the only thread
safety feature you really need here, i think, is to wrap your
result in a immutable object.
I am currently working on a different supposed optimization that I
think does enough BigInteger math as to make it prohibitively slow.
(It's optimization is that it is supposed to avoid costly modInverse
operations but to me it still even seems to require some of those so
it may prove to not be an optimization at all).
I'd suggest to build the BigInteger version as your reference
implementation! And then replace any internal use of them by a
byte[] to get to your optimization. And wrap the result in an
immutable class.
cheers
--
Eduard de Jong
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
