Work with Concurrent Library

The Solidity Gateway to Arcology Concurrency Control

Concurrent programming is a model in which multiple computational units execute independently and potentially simultaneously. Concurrent programming in centralized systems operates under weaker constraints.

In centralized systems:

• Non-deterministic scheduling is perfectly acceptable.

• The system can rely on locks, mutexes, or runtime scheduling control.

In blockchains:

• Every node must independently execute the same transactions.

• All nodes must reach the same final state.

• Execution must be deterministic across machines.

• Any divergence breaks consensus

The concurrent Library is an integral part of the Arcology concurrency control framework. it provides concurrency-safe data structures and execution primitives designed specifically for these blockchain constraints.

Why Using Concurrent Library

Arcology is 100% EVM-compatible. Developers can redeploy their applications without modification. The final state consistency is strictly guaranteed regardlessly. So why use concurrent library anyway? The answer is efficiency.

Arcology has a parallel execution engine, but since most Ethereum contracts were designed for sequential execution, while they run seamlessly on Arcology, in many cases, they won’t reach maximum efficiency. The concurrent library equips developers with the tools necessary to fully leverage parallel execution.

What Are in the Suite

The suite provides the following components to efficiently handle concurrent state modifications.

1. Cumulative Variables

A commutative variable can receive concurrent delta updates from parallel transactions, and the final result consistently remains the same, irrespective of the order in which the updates are processed.

2. Concurrent Data Structures

Arcology's concurrent data structuresare lockless specifically designed to handle concurrent data manipulation, and they are different from native data structures in a number of ways:

• Execution commutativity and state consistency are always guaranteed.

• Any violation of the commutativity guarantee triggers conflicts and reversions.

• The containers are managed by the Arcology's concurrent framework, not the EVM.

• They can only be accessed through the concurrent APIs.

• Their behaviors under concurrent environments are strictly defined.

Arcology's concurrent data structures can be considered a form of blockchain-specific Conflict-Free Replicated Data Types (CRDTs) designed to enable efficient and conflict-free updates.

• Concurrent Arrays: Merging thread-safe design with determinism to facilitate efficient parallel processing in multi-threaded environments. Resembling a conventional array, it permits concurrent push-back operations to the container and supports random reads, as long as they don't target the same elements.

• Concurrent Maps: Data structures combining the function of standard maps and arrays. A concurrent map differentiates itself from native mapping by providing the ability to iterate its keys and values deterministically.

• Custom Data structures: In addition, users can build the concurrent data structures of their choice based on the built-in ones provided by Arcology.

3. Tools

• Multiprocessing: spawn EVM instances programmatically with controlled depth and instance limits, similar to using multiple threads in general-purpose languages.

• Runtime: The package provides runtime information to developers, enabling Arcology to execute their transitions more effectively.

Contribution

Please feel free to contact us if you would like to contribute your own examples.