Just a heads up for this item.
A component called ActorDriver reads the Component's item "type" defined public.
Network.component() sets Component.type. This is a different thread, even though the component's thread is not running yet. Still the JVM must know.
In this circumstance we are forced to use volatile at the least. Because it is never updated again, only read, volatile suffice.
What volatile does is prevent the JVM from optimizing byte code (reordering, caching results in stead of publishing them, etc) and it forces the JVM to make the value public and visible to all threads using it.
We cannot evade this one.
J. Paul Morrison
Hi Guus, I suggest we forget about ActorDriver, Actor, Act1, Act2, and OutActor. These were strictly experimental, and never used to my knowledge. If someone used them when playing with JavaFBP, they never informed me! Let's add them to an "experimental" directory, and not waste any time on them! Thx. Paul
Well, for the volatility, it doesn't really matter (see remarks in first post).
I will move the ACTxxx out of the way though, into the testing arena. I suspect introducing an experimental package in the official jar still makes some testing a requirement. I would prefer to ignore them for the time being, until we have time to look at them more seriously.
If you agree, I will move them to testsrc, out of the official area.
Other thread safety issues
A second point is I found a lot of other volatile candidates, especialy annotaions. I had to turn priority into an AtomicInteger, because it gets updates multiple times.
Sorry, I don't see it - priority is set during the initialization phase where annotations are processed, and used before the process thread starts. The sole exception is the extra thread in Balloon, which is a different thread. You seem to be confusing the different phases of the run - and maybe that's my fault for not documenting things more clearly.
No, it is actually the same issue as with packetCount. It is published and as such viable to change by any thread in any user component.
However, I will remove this if you feel confident people will not get creative and change priority (I guess it is pretty unlikely).
It is also possible, that I confused the search for referenced fields with each other: which is why I mentioned it: I just knew you wouldn't like it :)
So let me know. If you trust it, I will change it back (but read my other mail first, where I explain the risks).
Updated Component.java, not finished yet, but still committed what I have now to svn.
The next step is checking out the ReentrantLock and the Condition. Before I do, I need to read up on them. They are in the advanced sector of threading and concurrency issues.
Moved the Actor and friends to the testsrc folder. Hope you are happy with that.
J. Paul Morrison