STM software transactional memory-essentially to improve concurrency, manage read and write access to memory through transactions to avoid lock usage

For Java programmers, we have a natural understanding of object-oriented programming (OOP), but language also greatly affects the way we build object-oriented applications. (now OOP has been very different from Alan Kay's original intention to create the word, his main idea is to use messaging and eliminate all state data (he argues that the system is made up of objects that are similar to biological cells that communicate through messaging, Without having to hold any status)--go language )

For Java programmers, when we find an instance along a pointer or reference, we actually log in to a piece of memory that holds its state, so manipulating the data in that position is a natural thing. The location represents the object instance and the data it contains. Merging entities with States initially seems to be very simple and easy to understand, but from a concurrency perspective, there are many serious negative consequences. For example, if we need to implement a program that prints bank account details (amount of money, current balance, transaction information, minimum balance, and so on), we will encounter many concurrency-related issues. You'll find that the reference you're working on is actually a proxy for a state that can change at any time. So when we look at the account information, we need to lock up to prevent other threads from making changes to the account content, which will inevitably lead to a significant decrease in concurrency. But the problem does not begin at the moment of lock-up, but when we merge the entity of the account with its state.

We have been told that object-oriented programming is the modeling of the real world. But sadly, the real world and the model that OO paradigms are trying to build are actually very different. Because in the real world, the state is constant, and the entity is constantly changing. Next we will discuss why this statement is correct.

Separating the entity from the state

Can you tell me quickly what Google's share price is now? We can of course say that the stock price is changing from the moment the stock market opens. As a simple example, December 10, 2010 Google's closing price is $592, and the number has been in the history books and will not change. Of course, Google's share price today is completely different from that day. And if you look at Google's share price after a few minutes (assuming the stock market is open), we'll see a different value, but the previous value hasn't changed. from now on, we have to change our understanding of the object, and this will also change the way we use the object. We'll see later how separating an object's entity from its immutable state value will help us achieve lock-independent programming, increase concurrency, and minimize competition.

separating the entity from the state is definitely a genius idea, which is a very critical step in the STM model process . Suppose our Google stock object consists of two parts: The first part represents the entity of the stock, which contains a pointer to the second part. The second part contains the latest stock price of the stock, where the variable holding the stock price is the immutable state, as shown in 1.

Figure 1 separating the variable-body part from the immutable state value

once a new share price is received, we can put it into the historical price index. Since the old stock price is immutable, we can share it for all threads to access. Google stock objects can be M.F.B. s to provide data read services. And once the new data is ready, we can quickly change the pointer in the entity so that it points to the field where the new stock price is saved. the separation of entities from State is also a great boon for concurrency. Because of this approach, we don't have to block any requests for stock prices. since the state is immutable, we can gladly pass its pointer to the thread that made the query request.

Transactions in the STM

The concept of transactions originates from the concept of database transactions in a database management system (DBMS). In a database management system, transactions must satisfy the acid nature, namely atomicity, consistency, isolation, and persistence. Atomicity means that the action in a transaction is either executed or not; consistency means that at any moment the database must be in a consistent state, i.e. certain pre-set conditions must be met; isolation means that a transaction cannot see the state of the internal objects involved in other uncommitted transactions. Persistence, however, means that a committed transaction must be permanent for the database system to change. Since the data in STM is all in memory rather than in the database or file system, STM provides only the first three properties of the transaction and lacks support for persistence. by encapsulating access to memory in transactions (transactions), STM eliminates the mistakes we make in multi-threaded memory synchronization!

In the Clojure language, the STM implementation uses a multi-version concurrency control technique (MVCC) similar to a database, and its concurrency control is much like the optimistic lock (optimistic locking) in the database. When we start a transaction, STM records the timestamp and copies a copy of all the ref in the transaction. Because the state is immutable, the copy of ref is M.F.B. S. When a "change" is made to an immutable state, we do not actually change its value, but instead create a copy of the new value for it. The copy is an internal state of the transaction, and because we use a persisted data structure, this step is M.F.B. s. If the STM recognizes that the ref we have manipulated has been changed by another transaction, it will abort and redo the transaction. When the transaction completes successfully, all changes are written to memory, and the timestamp is updated!

Transaction implementations in STM

The implementation of software transactional memory consists of atomic objects (Atomic object), Conflict Conflict Manager. The realization of atomic object is the most important, it is the medium of communication synchronization between each transaction. The implementation of atomic objects is divided into sequential implementations and transactional implementations: where transactional implementations also require synchronization and recovery (recovery) functionality, which means that the ability to detect transactional conflicts is required, while the recovery function means that the object needs to be rolled back to the state it was in before the transaction failed. The current proposed atomic object is generally based on a read/write conflict (read/write conflict) mechanism: The atomic object provides two interfaces, a read interface, a write interface, through the read interface can get a readable object, and through the write interface can be a writable object. In order to detect conflicts (that is, when multiple transactions are synchronized), you can set up two sets in a transaction, one for read sets, and one for write sets, respectively, to record the set of Read and write atomic objects to be processed by the firm. If the read set or write set of one transaction crosses the write set of another transaction, it indicates that there are two transaction conflicts that require the conflict decider to take further decisions.

Summary: STM software transactional memory-essentially to improve concurrency, manage memory read-write access through transactions to avoid lock-in use! For Clojure,akka, it simply encapsulates the operation of transactional memory as a transaction, simplifying concurrent programming and allowing programmers to worry about complex transactional synchronization issues!

STM software transactional memory-essentially to improve concurrency, manage read and write access to memory through transactions to avoid lock usage