On Oct 15, 2007, at 5:10 AM, Eduard de
Jong wrote:
Since ALL Java programs are inherently multi-threaded (think Timer,
AWT, SWING), it is an imperative to make any class thread safe.
This I'd say is a little too general. On
occasion I think threading concerns can be pretty much ignored. In the
cases you mention and many others they must be
considered.
My statement is that treading should be a concern to everyone
when designing code. One conclusion of focussing on these issues may
well be that the code does not require any special features. It is
always good to document these design decisions.
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.
This was one reason I thought this a
fairly good example. All manipulations being local clearly can't be a
threaded concern. This somewhat counters threading issues making
BigInteger use always compulsory.
BigInteger and all the immutable value classes are intended
for sharing values amongst objects which may live in
several threads and perform actions on the value unknown to the
designer of the value class. The use of BigInteger is one very
convenient way to safely share the result of a computation.
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.
That is about the approach I'm taking. A prototyping BigInteger
reference version and then a try at a optimized version less reliant
on BigInteger. I'm not quite sure I still see the need for the
immutable wrapper class but I will give it some thought. My own wnaf
class is not meant to be updated after it is instantiated so by intent
it is immutable. I think I do allow access to the representation
byte[] also so I may be in violation of that as well as the BigInteger
version.
Exposing the value representation is not the same as giving
access to the objects internals. The byte[] obtained from BigInteger
is a copy of its value, getting the copy doesn't change the value of
the original object. Having obtained a copy in this way, it now is
your responsibility to keep it's meaning intact.
In general, the value you extract, or for that matter insert at
construction time, in an immutable value class should be made by using
a deep copy, to make sure that no element of the value state can be
modified by another thread having a reference to the copy or keeping a
reference to the original, respectively.
One aspect of getting a copy of the value from an immutable
object, when the value isn't a primitive, is that its is in general
safe to use that copy as if it was completely confined to the thread
executing your own code. So you can use it in any way you need,
including changing it. The really paranoid should make a copy
again before use to make sure that the originating value class doesn't
secretly keep a reference to it and exposes that to another
thread.
I think it is a good design for four Wnaf class can deliver a
copy of its representation. It allows extensibility.
Mike
Hall hallmike at att dot
net
--
--
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
