Re: Optimising Variable to reduce instantiation overhead

On Fri 17 March 2006 11:31, Endre St=C3=B8lsvik wrote:
> On Mon, 13 Mar 2006, Alex Twisleton-Wykeham-Fiennes wrote:
> | On Mon 13 March 2006 12:34, Endre St=C3=B8lsvik wrote:
> | > On Sun, 12 Mar 2006, Alex Twisleton-Wykeham-Fiennes wrote:
> | > | All,
> | > |
> | > | more performance tweaks, this one to the org.webmacro.engine.Variab=
le
> | > | class.
> | >
> | > Excellent performance tuneup you're into, Alex!
> | >
> | > | - made the getVariableName() method check to see if _vname has been
> | > | initialised, and if not then build the name before returning it.=20
> | > | This is now synchronized as it changes the state of the object.
> | >
> | > So?
> |
> | If you don't synchronize then you could potentially have two threads
> | modifying the state of the Object simultaneously.
>
> Not unless your code allows multithreaded acccess to a _shared instance_.
> And you shouldn't, unless they absolutely have to exchange information
> through this object.

But it *is* shared as Keats said.

> |  In this situation it is not the end of the world, because the
> | generation of the result is a) not that expensive, and b) not dependent
> | on other mutable properties, but I find it best to apply thread-safe
> | approaches to everything that changes state and then remove them if
> | profiling shows it to be a problem.  Much better to start safe and then
> | remove redundant safety when required than to start unsafe and try and
> | make things safe when a weird multi-threading bug occurs...
>
> I don't agree: putting synchronized on every bleedin method "just because"
> is not a good strategy. If it can't be accessed by multiple threads, then
> multi-threading tactics aren't great. Beside hitting performance, they
> may potentially give you new exciting problems with deadlocks.

It is not "just because", it is "because it reads the state of a mutable=20
instance variable and then changes the state of the mutable instance variab=
le=20
based on the read value".

I would be very interested if you can show me a) some performance metrics t=
hat=20
show that my lazy synchronized initialisation is hitting performance, and b=
)=20
how my synchronized code can generate a deadlock.  I will of course then=20
change my implementation.

> | > Is it shared across threads?
> |
> | I'd have to double check this one.  It's a bit of a twisty turny passage
> | of Macro inheritance and it isn't necessarily obvious...
>
> What has inheritance to do with this?
>
> If an object that implements Macro is _shared across threads_, then _this_
> class should do synchs on methods that change its internal state (and
> generally not using the "method syncrhonziation" paradigm - read up on
> "monitors"). But why should the general Macro-implementing objects of
> WebMacro be shared across threads?!

Let's just assume that I don't know what I'm talking about for a moment. =20
Please explain at what point in the following I am on crack:-

=2D Macro is an interface. =20
=2D interfaces cannot specify synchronized in their declarations according =
to=20
the java language definition. =20
=2D Variable implements Macro.
=2D Variable has a method that checks for an internal variable to see if it=
 is=20
null and sets it if it is null.
=2D I would like this initialisation to only occur once so I want to synchr=
onize=20
on something to achieve this.
=2D I can't synchronize on the variable because it is null (initially)
=2D I'm therefore left with the choice of synchronizing on the Object itsel=
f or=20
creating a second Object inside the Variable to synchronize on.

Am I missing something?

> | ps synchronizing is really not the overhead that it used to be in older
> | JVMs and it *really* makes your life easier to not have any
> | multi-threading bugs...
>
> Contended synchs are hell in any case.
>
> A synch, contended or not, have to flush all dirty cache to memory whether
> or not it is necessary. This is bad, and one should _not_ use synchs
> unless it is multithreaded accessed.=20

But it *is* multithreaded accessed.  And even if it wasn't, you are not sur=
e=20
that it isn't or that it won't be in the future, so you write your code saf=
e=20
and then optimise it when / if performance becomes an issue.

Alex


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642