It depends on where the problem is. You own code can be arranged so that there
is only one shared variable[*], and only two synchronised sections at all, both
/very/ short (one to read it, one to write it). You can be certain that /that/
synchronisation isn't an issue.
My model, the various mathematical algorithm classes, does their work
in a separated thread but I've no synchronization on data, because I'm
not interested in the coherence between displayed data, the can be part
of 2 successive steps of elaboration and I would not have any problem
with this.. so the only thing that I do is to notify that a component
of the model updated its status, which is usually a set of
multidimensional arrays.. some display classes are connected as
observers to the model, when they receive the notification the repaint
method is called.. or a timer is started to call repaint.
the paint method of each visualization class read data from one of the
component status and build a the visualization.. i.e. one visualization
takes the position of a graph nodes from the weights of a neural
networks.. calls a method to transform them in 2d position and then
uses another net activation to select color and another one to select
the connections..
not all the components are update at each steps.. and the model and the
visualization are changed often and their status is big.. however all
is update in a serial manner so no synchronization is needed inside the
model.. but I don't know what is the behavior of the system when the
swing thread read data from inside the model.. It's long time (if i
ever was a time) since i've used multithread.
But given your profiling results, it appears that the lock handling within
AWT/Swing is also getting in on the act. I can't see how it's managing it, but
your results are consistent with the idea that a new repaint request can't be
queued (the attempt will block) while your paint() (or paintComponent()) code
is active.
One thing to check is what locks your own paint() (etc) methods hold, and for
how long. If you have made that whole method synchronised then that might well
cause problems.
no I've not used the synchronised keyword in all the project..
BTW, please don't be offended, but I think your problems here are coming from
trying too hard to optimise the wrong things. Copying is cheap, holding locks
is not. Similarly, if your simulation generates new data while the display
loop is trying to paint the old stuff, then that just doesn't matter.
You are right but i believed that the repaint call would be merged in
one call, and I've not a display loop, the display is triggered by the
model.. any visualization that is related to the model is notified of
the change and if it is in autorepaint mode it calls repaint..
Building a snapshot is not so easy.. there are various MB of data and
not all is required to be repainted, and the structure of the data is
somewhat complex.. it is not a simple call to system.arraycopy..
perhaps.. one way could be to let the system to only mark as dirty
...and copy to a buffer... to display... but i wouldn't be easier to
stop the algorithm display and continue or not to stop it and
continue..?
Finish
displaying the old stuff (which will only be out of date by an inconsequential
margin), and then (on the next tick) go back to the simulation for the most
recent snapshot. You don't need to worry about whether the AWT/Swing code
merges successive update requests, because you are not issuing them fast enough
for that to matter. You don't need to worry about falling behind the
simulation, because at each tick, you are always displaying the most recent
snapshot. The simulation loop is /certainly/ worth putting effort into
optimising. And your actual display code may well benefit from some
profiling/optimisation too. But getting data from the producer to the consumer
should not be enough of a bottleneck to worry about.
You are right.. but i was thinking about some kind of errorr in the
repaintmanager..
At last the question is:
my system doesn't need to synch the display code with the symulation
steps, so I've not used any synchronized method... only call to repaint
when needed.. and I'm now using for some classes a timer that is
started by the notification and at last call repaint.. it seem to work
for heavy weight visualizations.. do you think that with a complex
structure like that of mine simulator, is coping data still usefull?
thanks
dimitri