I have committed the optimized controller state model and updated AbstractController to
I removed ControllerStateModel from AbstractController's interfaces and removed the
methods. The new ControllerStateModel lives here:
and the legacy one lives here"
"kabir" wrote :
| One minor issue is the iterator() and listIterator() methods, which are not thread
safe at the moment. The other methods are called with a lock taken in AbstractController.
For the iterator methods I need to readLock, take a snapshot into a list and return
iterators to that list.
This was wrong, although AbstractController holds locks when accessing the states, others
may use it without locks taken, e.g.
| controller.getStates.isAfterState(state1, state2)
Since MapControllerStateModel keeps tracks of a few different things (as opposed to
ListControllerStateModel which is backed by a single concurrent list), I am unsure whether
read/write locks should be used there. I am pretty sure that the way I have set it up, it
should be safe to use, but you might want to review this. In any case having read/write
locks in MapCSM should still outperform ListCSM although I haven't actually measured
that. I'll check that if consensus is that MapCSM needs locks
View the original post :
Reply to the post :