commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [Math] Synchronization
Date Sun, 22 Jul 2012 09:51:50 GMT
Hi Gilles,

On 22/07/2012 02:43, Gilles Sadowski wrote:
> On Sat, Jul 21, 2012 at 11:44:43AM -0700, Ted Dunning wrote:
>> Synchronization in low level code is generally really bad.  This is the
>> whole point of why Vector was essentially thrown away in Java collections
>> in favor of ArrayList.
> 
> I might be wrong, but I don't think that's the reason.
> At the beginning there was the "Vector"... and nothing else. In singly
> threaded code or as a thread local variable, synchronization is an
> unnecessary waste of time. Since most code falls into this category,
> "ArrayList" is indeed much more useful. That doesn't imply that there is
> never a need for synchronization in low-level code.
> 
> In the present case, AFAICT the synchronization is a performance gain during
> the creation of the data (to be cached). Once that part is done, user code
> do not call any "synchronized" methods, so no loss there.
> 
>>
>> Better to synchronize in the caller who knows about the multi-threading.
>>  Or simply build a synchronized wrapper in an inner class.

Note that there are also other mechanisms apart from synchronization
that could be used. The lazy holder idiom can be used to ensure single
execution and both locks and atomic variables from the concurrency
package can be used for thread safety (I strongly prefer them to
synchronization).

One important point too is that regardless of the fact we use
multi-threading in [math] or not by ourselves, we should take care to
allow upper level application to use our classes in multi-threaded
environments. This is simple for small container classes (3D vectors,
complex numbers ...) that can be made immutable (at least the original
class we provide, not the derived class users may create). This is much
more complex or can even be impossible for long algorithms with an API
providing lots of different functions (core engine run, setters,
getters, retrieval of partial results ...). Documenting everything about
thread safety would be a daunting task, but it would be a nice thing to
have, at least for some classes or methods.

Luc

> 
> Please show how this fits with the current case, and improves the
> implementation.
> 
> 
> Thanks,
> Gilles
> 
>>
>> On Sat, Jul 21, 2012 at 6:08 AM, Gilles Sadowski <
>> gilles@harfang.homelinux.org> wrote:
>>
>>>>
>>>> Note that there is a performance price for the synchronization,
>>>> which may outweigh the benefit of adding it.
>>>
>>> I thought of adding that because one might want to parallelize the
>>> integration computations while the quadrature rules factory is shared.
>>> [See e.g. MATH-827, line 41 in the posted code.]
>>> Without "synchronized", all threads will compute all the rules.
>>>
>>> On my machine (4 cores), in the absence of synchronization, the above test
>>> indicated that the "computeRule" method was called 18 times!
>>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message