You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 48a7655
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: book/en-us/07-thread.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -330,11 +330,11 @@ int main() {
330
330
Multiple threads executing in parallel, discussed at some macro level, can be roughly considered a distributed system.
331
331
In a distributed system, any communication or even local operation takes a certain amount of time, and even unreliable communication occurs.
332
332
333
-
If we force the operation of a variable `v` between multiple threads to be atomic, that is, any thread after the operation of `v`
334
-
Other threads can **synchronize** to perceive changes in `v`, for the variable `v`, which appears as a sequential execution of the program, it does not have any efficiency gains due to the introduction of multithreading. Is there any way to accelerate this properly? The answer is to weaken the synchronization conditions between processes in atomic operations.
333
+
If we force the operation of a variable `v` between multiple threads to be atomic, that is, in any thread after the operation of `v`,
334
+
other threads can **synchronize** to perceive changes in `v`, thus for the variable `v`, the operations appear as a sequential execution of the program. In this case, it does not have any efficiency gains using multithreading. Is there any way to accelerate this properly? The answer is to weaken the synchronization conditions between processes in atomic operations.
335
335
336
336
In principle, each thread can correspond to a cluster node, and communication between threads is almost equivalent to communication between cluster nodes.
337
-
Weakening the synchronization conditions between processes, usually we will consider four different consistency models:
337
+
To weaken the synchronization conditions between processes, usually we will consider four different consistency models:
338
338
339
339
1. Linear consistency: Also known as strong consistency or atomic consistency. It requires that any read operation can read the most recent write of a certain data, and the order of operation of all threads is consistent with the order under the global clock.
340
340
@@ -349,7 +349,7 @@ Weakening the synchronization conditions between processes, usually we will cons
349
349
350
350
In this case, thread `T1`, `T2` is twice atomic to `x`, and `x.store(1)` is strictly before `x.store(2)`. `x.store(2)` strictly occurs before `x.load()`. It is worth mentioning that linear consistency requirements for global clocks are difficult to achieve, which is why people continue to study other consistent algorithms under this weaker consistency.
351
351
352
-
2. Sequential consistency: It is also required that any read operation can read the last data written by the data, but it is not required to be consistent with the order of the global clock.
352
+
2. Sequential consistency: It is also required that any read operation can read the last data written by the data, but it is not required to be consistent with the order of the global clock. The order within each thread is reserved(?).
0 commit comments