for app development, what concurrency model should I use?

[Deleted user (ghost)]

I did not find document talking about concurrency question, I have some question about that, I listed below.

1. does ccf use ringbuffer between host and enclave to implement a concurrency model like multiplexing?
2. if ccf app is concurrent, what synchronization primitives should I use?
   As far as I know, ccf is based on openenclave, when I read https://github.com/openenclave/openenclave/blob/master/docs/LibcSupport.md and https://github.com/openenclave/openenclave/blob/master/docs/LibcxxSupport.md , I found Synchronization primitives are not secure across calls to host., so if ccf app is concurrent, what synchronization primitives should I use?

[Amaury Chamayou (achamayou)]

There's a bit of detail about threading here: https://microsoft.github.io/CCF/main/overview/threading.html

1. Yes, there is an input ringbuffer where the host writes TCP frames, consumed by a single in-enclave dispatcher thread that hands over tasks to in-enclave worker threads via in-enclave message queues.
2. Application code is never expected to deal with concurrency or use synchronisation primitives directly. A single handler only ever executes on the same thread, and state not scoped to a handler's execution must be kept in the KV store where it is safe to access from multiple handlers.

We will try to make this more apparent in the documentation, but CCF is really a framework, not a library. The application is defined as a collection of endpoint handlers, which are triggered and executed by the framework in response to RPCs. Concurrency, re-execution on conflicts, forwarding to the primary etc are handled by the framework entirely, transparently for the handlers.

[Deleted user (ghost)]

Amaury Chamayou (@achamayou) sorry, I had a new question about KV store, suppose a table T(string => int) and two handlers(H1 and H2) that want to mutate key "a" from T, could it possibly happen like this execution sequence in multi-thread(or single thread)?

H1                 | H2
++++++++++++++++++ | +++++++++++++++++
x = READ from "a"  |
                   | y = READ from "a"
WRITE x+1 to "a"   |
                   | WRITE y+10 to "a"

key "a" has initial value 0, the final result is 10 instead of 11.

if it is possible, how can I prevent that? thank you.

[Amaury Chamayou (achamayou)]

It's not possible, transactions are atomic. Each transaction "sees" a KV snapshot at a given read version throughout its execution. When the time comes to commit the transaction, if some of the read set has since been modified, the transaction is re-executed against a later snapshot including the latest writes.

[Deleted user (ghost)]

Amaury Chamayou (@achamayou) what the transaction did you actually mean? the whole RPC endpoint handler or the operation set of a kv::Tx (even a map handler)? the re-execute is to re-execute the RPC endpoint handler, right?

[Amaury Chamayou (achamayou)]

@svenFeng Each invocation of an RPC endpoint handler is provided with a single kv::Tx instance, representing a KV transaction. Sorry for the confusion, when I said the transaction is re-executed, I did mean the RPC endpoint handler, provided with a fresh kv::Tx instance, the previous (conflicting instance) having been discarded.

[Deleted user (ghost)]

It solve my question, thank you very much.