Hi.
> [...]
[...]
<side rant>Historically, we did not care about thread-safety at all
in [math], assuming the standard use case was *always* going to be
one instance per thread. The statistics aggregators are an example
where multithreaded access makes sense, but this is much more the
exception than the rule in [math]. I would really like to get clear
on which classes really need to be threadsafe themselves rather than
blindly assuming that all do and insisting that everything be
immutable so that we don't have to think about how to make things
threadsafe.</side rant>
We would be more able to advance if we consider that "threadsafe
and "immutable" are _not_ interchangeable.
We have seen (in Commons Math also) that immutability can provide
thread-safety in a cheap way. Immutability is mostly easy to
implement when an object's fields are initialized with data that is
guaranteed to not be held by another object, and whose accessors
will forbid modification.
Alois, it seems that "final" is (was?) useful for performance
reason. [But again, this would probably be noticeable only with
many allocations. Is there such a case for optimizer objects?]
However, designing a class to be immutable is not always cheap. An
example is the combination that is the subject of this thread; here,
"costly" means: a lot of repetitive code lines[1], which could be
easily avoided by dropping immutability, without loosing anything
because:
1. the code is _not_ threadsafe anyways (with or without "final"),
2. the code could be made thread-safe, with or without "final".
Hence, I think that when the functionality is well circumscribed,
and it is easy to make everything "final", it's worth it. But when
it's not that easy, we should indeed not insist on it[2] without
1. use-cases that show the need for multi-threaded usage of the
class, and
2. providing proof that immutability does indeed bring thread-safety.
I still think that CM should care about multi-threading (reasons
detailed in other posts) but we should focus on tasks where the
developers can readily _measure_ the benefits rather than spend (a
lot of) time designing complex schemes which are not required by
common use-cases.
In addition to "stat", a few other CM areas where MT is of direct
application are: FFT, Genetic Algorithms, Machine-learning, ...
Regards,
Gilles
> [...]
[1] Cf. diff (in recent commits of optimizer classes in package
"o.a.c.m.fitting.leastsquares") between mutable and immutable
versions of the code.
[2] Because we loose something on the "simplicity" side.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
