First of all, it is a good style to set attributes as final if they haven been designed as immutable. I should have done this in my examples for attributes like guard or executors. Because the executors or the guard object never changes, there wouldn’t be situations where threads will see different values. That means the implementation will work as predicted. But the variable isRunning should haven been declared as volatile as you mentioned.
I didn’t see the advantage to use a java.util.concurrent.locks.Lock object instead of synchronized in my examples. My intention was to keep the examples simple and correct. Using Lock objects depends on the concrete implementation. For example if you have to implement algorithms like hand-over-hand locking you will use Lock objects.
The idea of synchronizing on con is to avoid concurrent call backs calls (performed by the worker threads) for the same connection instance. That means other call back methods like onConnect or onIdleTimeout have to be synchronized in the same way. By doing this, the call back methods will be performed in a serialized manner.
Synchronizing connection’s methods like write(…), readInt() would be another topic. |
java.net RSS Feeds
