Hi sebb, Thanks for answers. This should be investigated as the gain of removing synchronized and switching to volatile is huge 25% more throughput on Javascript function for example with 10 threads. The more you add threads the more you gain. And we have customers reporting locking due to _javascript , Thread dump shows 1 thread blocking others on execute.
Regards On Thu, Oct 16, 2014 at 4:55 PM, sebb <[email protected]> wrote: > > On 14 October 2014 19:57, UBIK LOAD PACK Support > <[email protected]> wrote: > > Hi, > > Reviewing code of Functions in JMeter we don't understand why Functions > > that only have values as instance variable (so Beanshell or > StringFromFile > > or IterationCounter (which could be improved to avoid it) are not > > concerned) synchronize on execute. > > > > It appears "values" instance variable is initialized within > > StandardJMeterEngine thread and then only accessed in read mode by > > JMeterThread > > i.e. it is written in one thread and read in another > > > But it is true that if synchronized is removed then CompoundVariable is > > accessed by multi threads but it seems it uses thread related data so it > > should be OK. > > No, because the Java Memory Model only guarantees safe publication of > a mutable field if the writer and reader synchronize on the same lock. > Or the field must be volatile. JMeter was originally written for Java > 1.4 (or earlier); I think volatile did not offer the safe publication > guarantee then. > > It does look like the values field could now be made volatile, which > would mean the synch. was not needed to ensure safe pub. > However, it might still be needed for other fields or mutual exclusion > purposes. > > > > > > > -- > -- Regards Ubik Load Pack <http://ubikloadpack.com> Team Follow us on Twitter <http://twitter.com/ubikloadpack> Cordialement L'équipe Ubik Load Pack <http://ubikloadpack.com> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
