No, you do not have to declare any private state volatile, since the very act of scheduling involves synchronization, and that would 'effectively flush’ (1) to RAM. You can call ordinary synchronized methods as you have shown.
However, you CANNOT call pausable methods within a synchronized block. The weaver will recognize it and not allow it. The reason is as follows:
'synchronized' gets translated to a pair of monitorenter and monitorexit VM calls. At monitorenter, the VM associates the monitor’s lock with the thread from which it is being called. Clearly, it makes no sense for the rest of the code including monitorexit to run in a different thread. The VM detects this at run-time and throws a runtime exception. We detect this at compile time and disallow it.
If you must use locks, you can use kilim’s locks that are aware of this behavior.
Hope this helps.
—sriram.