Re: Optimising Variable to reduce instantiation overhead

| >
| > 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.

I do think that you know your stuff, and the optimzations you're doing to 
WebMacro now are _just great_. I guess there is some underlying 
disagreement to some small aspects of multithreading here, read at end.

| Please explain at what point in the following I am on crack:-
| 
| - Macro is an interface.  
| - interfaces cannot specify synchronized in their declarations according to 
| the java language definition.  
| - Variable implements Macro.
| - Variable has a method that checks for an internal variable to see if it is 
| null and sets it if it is null.
| - I would like this initialisation to only occur once so I want to synchronize 
| on something to achieve this.
| - I can't synchronize on the variable because it is null (initially)
| - I'm therefore left with the choice of synchronizing on the Object itself or 
| creating a second Object inside the Variable to synchronize on.
| 
| Am I missing something?

Well, no, not unless the option suggested by Keats should be counted as a 
miss.

But if this thing only synchs on the one explicit feature (the 
name-thingy), then it definately should have its own synch - or else 
you'll create "false contention". But avoiding synchs altoghether is 
definately the best - using immutables, and/or "instances are created per 
context" or similar logic.

I can't understand that much anything in WebMacro should be shared, less 
the Templates itself due to "precalculations" using the introspection 
engine stuff. But the templates should again not contain any _state_, so 
that they can be shared as an immutable.

| 
| > | 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. 
| 
| But it *is* multithreaded accessed.  

Okay - then "the Keats option" is .. an option. But why is it multitreaded 
accessed?

| And even if it wasn't, you are not sure 
| that it isn't or that it won't be in the future, so you write your code safe 
| and then optimise it when / if performance becomes an issue.

I guess it is here we disagree. I think that the javadoc should state 
"this ain't multithread-safe, don't share it, or else do synchs yourself", 
like the Collections framework, or maybe "instances of this class are 
immutable, so share it as much as you want"

You're probably in the StringBuffer, Vector, Hastable camp, while I'm 
firmly in the other camp when it comes to synching: StringBuilder, 
ArrayList, Hashmap.

Regards,
Endre.


-------------------------------------------------------
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