On restore the "main" thread is started before the Resource's afterRestore has completed

[Anton Kozlov]

On 4/6/23 16:59, Christian Tzolov wrote:
> Then given your original suggestion is it right to assume that the “guard access to the resource” now should guard the ProcessorState not the ProcessorContext?

I'm not sure about the difference between Context and State, as both look like a state Processor uses.

For the discussed RWLock approach, it may look like [1]. That is, accessing the state needs to be done under Read lock. The beforeCheckpoint() locks the corresponding Write lock, thus blocking access to the state until the afterRestore releases the Write lock.

Was ProcessorState intended for modification? Or in the example that means something that we don't control, or is too complex to control, so do we'd like to keep modifications limited to ProcessorContext? In this case, we need some synchronization between Processor and the ProcessorContext, like [2].

Do these options work for you?

These are probably not the best approaches for the example, rather demo what we mean by RWLock. RCULock being implemented by Radim will reduce the overhead of the Read part of the lock, but the semantics will be the same.

[1] https://github.com/tzolov/crac-demo/compare/main...AntonKozlov:crac-demo:main
[2] https://github.com/tzolov/crac-demo/compare/main...AntonKozlov:crac-demo:proc-sync

> And if this is true then how one would be able to identify all possible “resources” to be guarded?

Resource usually refers to something outside the Java program, a file, socket, or pipe,.. which represents a higher-level link of the program with the world.

There is no real need to add CRaC Resource in this example. If you need that, I assume it's required because of links with the world. Which will be detected and reported by CRaC implementation if they exist at the checkpoint. Or that somehow relates to the program logic.

Thanks,
Anton