[
https://issues.apache.org/jira/browse/MATH-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14049077#comment-14049077
]
Phil Steitz commented on MATH-1134:
-----------------------------------
Yes, we are dealing with cached member data here. There are four logical
options, that I will list in my personal order of preference
0) Revert the change and just document that the class is not threadsafe. This
sounds wimpy, but basically the choice is between burdening all users of the
class with the overhead associated with one of the other options or just
burdening those who actually want to use instances as singletons with
protecting them themselves. That is the strategy we have used elsewhere and it
has always made sense to me - users who use math objects that have internal
state know better than us what the concurrency context of their applications
are and can eat all and only the overhead they need to ensure correctness of
their code. We should make it clear which objects maintain internal state and
mark them as not threadsafe, but we should not force ourselves to precompute
everything or forego caching / mutability to maintain threadsafety everywhere.
1) Protect the cached data by synchronizing access to it (adding sync blocks /
explicit locks where needed)
2) Get rid of the caching - actually compute the partials each time they are
requested
3) State of trunk as of r1606940 (force cache preload at construction)
Gilles suggestion to make 3) itself configurable sort of combines 3) and 0)
IIUC what he is suggesting.
> unsafe initialization in BicubicSplineInterpolatingFunction
> -----------------------------------------------------------
>
> Key: MATH-1134
> URL: https://issues.apache.org/jira/browse/MATH-1134
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Derek Scherger
> Priority: Minor
>
> The lazy initialization of the internal array of partialDerivatives in
> BicubicSplineInterpolatingFunction is not thread safe. If multiple threads
> call any of the partialDerivative functions concurrently one thread may start
> the initialization and others will see the array is non-null and assume it is
> fully initialized. If the internal array of partial derivatives was
> initialized in the constructor this would not be a problem.
> i.e. the following check in partialDerivative(which, x, y)
> if (partialDerivatives == null) {
> computePartialDerivatives();
> }
> will start the initialization. However in computePartialDerivatives()
> partialDerivatives = new BivariateFunction[5][lastI][lastJ];
> makes it appear to other threads as the the initialization has completed when
> it may not have.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
