Terminology, Concepts（说明）
In this chapter we attempt to establish a common terminology to define a solid ground for communicating about concurrent, distributed systems which Akka targets. Please note that, for many of these terms, there is no single agreed definition. We seek to give working definitions that will be used in the scope of the Akka documentation
因为以下很多术语没有统一的解释，以下的说明强调其在Akka中的有效作用。
Concurrency vs. Parallelism（并发与并行）
Concurrency and parallelism are related concepts, but there are small differences. Concurrency means that two or more tasks are making progress even though they might not be executing simultaneously. This can for example be realized with time slicing where parts of tasks are executed sequentially and mixed with parts of other tasks. Parallelism on the other hand arise when the execution can be truly simultaneous.
并发：有两个或两个以上的任务在执行，但是它们不需要在同一时刻执行。例如，这可以通过时间切片来实现，其中部分任务按顺序执行并与其他任务的部分混合。
并行：有两个或两个以上的任务在执行，但是它们必须在同一时刻执行。
Asynchronous vs. Synchronous（异步与同步）
A method call is considered synchronous if the caller cannot make progress until the method returns a value or throws an exception. On the other hand, an asynchronous call allows the caller to progress after a finite number of steps, and the completion of the method may be signalled via some additional mechanism (it might be a registered callback, a Future, or a message).
A synchronous API may use blocking to implement synchrony, but this is not a necessity. A very CPU intensive task might give a similar behavior as blocking. In general, it is preferred to use asynchronous APIs, as they guarantee that the system is able to progress. Actors are asynchronous by nature: an actor can progress after a message send without waiting for the actual delivery to happen.
同步：在方法返回或抛出异常前，方法的调用者不能继续执行。
异步：在方法返回或抛出异常前，允许方法的调用者在等待有限步骤后，继续执行。
实现同步的方法：1.阻塞线程；2.执行CPU密集的任务。
一般推荐使用异步API，因为这样能确保系统能够执行。
Non-blocking vs. Blocking（非阻塞与阻塞）
We talk about blocking if the delay of one thread can indefinitely delay some of the other threads. A good example is a resource which can be used exclusively by one thread using mutual exclusion. If a thread holds on to the resource indefinitely (for example accidentally running an infinite loop) other threads waiting on the resource can not progress. In contrast, non-blocking means that no thread is able to indefinitely delay others.
Non-blocking operations are preferred to blocking ones, as the overall progress of the system is not trivially guaranteed when it contains blocking operations.
阻塞：一个线程无限期的延迟，导致其他的线程无限期的延迟，就称为阻塞。例如，一个独占资源被一个线程占有，该线程可能在执行一个无限期的循环，那么，直到占有资源的线程释放资源之前，其他线程都无法顺利的执行。
非阻塞：没有线程能无限制的延迟其他线程。
Operating Systems Study Guide
Blocking and Nonblocking I/O
Some control over how the wait for I/O to complete is accommodated is available to the programmer of user applications. Most I/O requests are considered blocking requests, meaning that control does not return to the application until the I/O is complete. The delayed from systems calls such read() and write() can be quite long. Using systems calls that block is sometimes called synchronous programming. In most cases, the wait is not really a problem because the program can not do anything else until the I/O is finished. However, in cases such as network programming with multiple clients or with graphical user interface programming, the program may wish to perform other activity as it continues to wait for more data or input from users.
阻塞会延迟用户请求，而用户则希望在等待服务器返回的时候执行其他任务。
One solution for these situations is to use multiple threads so that one part of the program is not waiting for unrelated I/O to complete. Another alternative is to use asynchronous programming techniques with nonblocking system calls. An asynchronous call returns immediately, without waiting for the I/O to complete. The completion of the I/O is later communicated to the application either through the setting of some variable in the application or through the triggering of a signal or call-back routine that is executed outside the linear control flow of the application.
通过非阻塞代码编写的异步程序能解放用户的等待时间。
Blocking I/O system calls (a) do not return until the I/O is complete. Nonblocking I/O system calls return immediately. The process is later notified when the I/O is complete.
A good example of nonblocking behavior is the select() system call for network sockets. Using select(), an application can monitor several resources at the same time and can also poll for network activity without blocking. The select() system call identifies if data is pending or not, then read() or write() may be used knowing that they will complete immediately.
Note
Correct asynchronous programming can be complex, but since asynchronous programs have only one thread of execution, problems of Deadlock and Data Inconsistency are eliminated. For this reason, several programming frameworks exist that handle the difficult I/O issues making asynchronous programming much easier.
Asynchronous programming with call backs appears to be the most common approach for graphical user interface programming. It also has some advocates in the network programming realm, but multi-threaded programming is more often used with network programming.
Deadlock vs. Starvation vs. Live-lock（死锁、 饥饿与活锁）
Deadlock arises when several participants are waiting on each other to reach a specific state to be able to progress. As none of them can progress without some other participant to reach a certain state (a “Catch-22” problem) all affected subsystems stall. Deadlock is closely related to blocking, as it is necessary that a participant thread be able to delay the progression of other threads indefinitely.
死锁：在一个系统中有多个参与者，当多个参与者为了执行，而相互等待对方达到特定状态，就会出现死锁。在其他参与者无法达到某个状态（“Catch-22”问题）的情况下，它们都无法执行，因此所有受影响的子系统都会停止。 死锁与阻塞密切相关，因为参与者线程必须能够无限期地延迟其他线程的进程。
In the case of deadlock, no participants can make progress, while in contrast Starvation happens, when there are participants that can make progress, but there might be one or more that cannot. Typical scenario is the case of a naive scheduling algorithm that always selects high-priority tasks over low-priority ones. If the number of incoming high-priority tasks is constantly high enough, no low-priority ones will be ever finished.
饥饿：在死锁的情况下，没有参与者可以执行，而相反，当有参与者可以执行，但可能有一个或多个参与者不能执行，就会发生饥饿。 典型的场景是一钟简单调度算法，它总是选择高优先级任务而不是低优先级任务的情况。 如果传入的高优先级任务的数量一直足够高，则永远不会完成低优先级任务。
Livelock is similar to deadlock as none of the participants make progress. The difference though is that instead of being frozen in a state of waiting for others to progress, the participants continuously change their state. An example scenario when two participants have two identical resources available. They each try to get the resource, but they also check if the other needs the resource, too. If the resource is requested by the other participant, they try to get the other instance of the resource. In the unfortunate case it might happen that the two participants “bounce” between the two resources, never acquiring it, but always yielding to the other.
Livelock occurs when two or more processes continually repeat the same interaction in response to changes in the other processes without doing any useful work. These processes are not in the waiting state, and they are running concurrently. This is different from a deadlock because in a deadlock all processes are in the waiting state.
Example:
Imagine a pair of processes using two resources, as shown:
|
|
Each of the two processes needs the two resources and they use the polling primitive enter_reg to try to acquire the locks necessary for them. In case the attempt fails, the process just tries again.
If process A runs first and acquires resource 1 and then process B runs and acquires resource 2, no matter which one runs next, it will make no further progress, but neither of the two processes blocks. What actually happens is that it uses up its CPU quantum over and over again without any progress being made but also without any sort of blocking. Thus this situation is not that of a deadlock( as no process is being blocked) but we have something functionally equivalent to deadlock: LIVELOCK.
活锁： 两个执行单元抢占两个资源，当他们同时获取到其中一个资源的时候，在获取第二个资源失败的情况下，都会无限制的尝试重新获取。这样，最后的结果就是这两个执行单元没有发生阻塞，但它们的工作并没有实际的推进下去。
Race Condition（竞态条件）
We call it a Race condition when an assumption about the ordering of a set of events might be violated by external non-deterministic effects. Race conditions often arise when multiple threads have a shared mutable state, and the operations of thread on the state might be interleaved causing unexpected behavior. While this is a common case, shared state is not necessary to have race conditions. One example could be a client sending unordered packets (e.g UDP datagrams) P1, P2 to a server. As the packets might potentially travel via different network routes, it is possible that the server receives P2 first and P1 afterwards. If the messages contain no information about their sending order it is impossible to determine by the server that they were sent in a different order. Depending on the meaning of the packets this can cause race conditions.
竞态条件：现在有一组假设好的事件，有可能被外部的不确定的事件影响，这被称为竞态条件（个人觉得翻译成竟态场景更好理解）。
当多个线程具有共享的可变状态时，经常会出现竞争条件，并且线程对该状态的操作可能会交错，从而导致意外行为。 虽然这是一个常见的情况，但共享状态并不是竞争条件所必需的。 一个示例可能是客户端向服务器发送无序数据包（例如 UDP 数据报）P1、P2。 由于数据包可能会通过不同的网络路由传输，因此服务器可能会先接收 P2，然后再接收 P1。 如果消息不包含有关其发送顺序的信息，则服务器无法确定它们是以不同的顺序发送的。 而数据包默认是按顺序到达，按顺序解码，根据数据包的含义，这可能会导致竞争条件。
Non-blocking Guarantees (Progress Conditions)（非阻塞的保证条件）
As discussed in the previous sections blocking is undesirable for several reasons, including the dangers of deadlocks and reduced throughput in the system. In the following sections we discuss various non-blocking properties with different strength.
下面讨论几种非阻塞的条件。
Wait-freedom（无等待）
A method is wait-free if every call is guaranteed to finish in a finite number of steps. If a method is bounded wait-free then the number of steps has a finite upper bound.
无等待：如果一个方法在每次的调用中都能在有限的步骤中完成，那么称其为无等待方法。
有限的无等待：如果方法执行的步骤存在一个上界，那么称为有限的无等待方法。
From this definition it follows that wait-free methods are never blocking, therefore deadlock can not happen. Additionally, as each participant can progress after a finite number of steps (when the call finishes), wait-free methods are free of starvation.
根据这个定义，无等待方法永远不会阻塞，因此不会发生死锁。 此外，由于每个参与者都可以在有限数量的步骤后（调用完成时）继续前进，因此无等待方法不会出现饥饿。
Lock-freedom（无锁）
Lock-freedom is a weaker property than wait-freedom. In the case of lock-free calls, infinitely often some method finishes in a finite number of steps. This definition implies that no deadlock is possible for lock-free calls. On the other hand, the guarantee that some call finishes in a finite number of steps is not enough to guarantee that all of them eventually finish. In other words, lock-freedom is not enough to guarantee the lack of starvation.
无锁定是比无等待弱的属性。 在无锁调用的情况下，保证某些方法在有限数量的步骤中完成。 这个定义意味着无锁调用不可能发生死锁。 另一方面，保证某些调用在有限数量的步骤中完成并不足以保证所有调用最终都完成。 换句话说，无锁不足以保证没有饥饿。
Obstruction-freedom（无阻碍）
Obstruction-freedom is the weakest non-blocking guarantee discussed here. A method is called obstruction-free if there is a point in time after which it executes in isolation (other threads make no steps, e.g.: become suspended), it finishes in a bounded number of steps. All lock-free objects are obstruction-free, but the opposite is generally not true.
无障碍是这里讨论的最弱的非阻塞保证。 如果某个方法在调用之后独立执行（调用它得线程不执行任何步骤，例如：变为挂起），则该方法称为无障碍方法，它在有限数量的步骤中完成。 所有无锁对象都是无障碍的，反之则有可能不成立。（理解：该方法有可能在内部加锁，但不能影响调用者的执行）。
Optimistic concurrency control (OCC) methods are usually obstruction-free. The OCC approach is that every participant tries to execute its operation on the shared object, but if a participant detects conflicts from others, it rolls back the modifications, and tries again according to some schedule. If there is a point in time, where one of the participants is the only one trying, the operation will succeed.
乐观并发控制 (OCC) 方法通常是无障碍的。 OCC 方法是每个参与者都尝试在共享对象上执行其操作，但是如果参与者检测到来自其他人的冲突，它会回滚修改，并根据某个时间表再次尝试。 如果有一个时间点，只有其中一个参与者在尝试，操作就会成功。
扫一扫
163
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
