Chapter 11 signal (I) - concept

Chapter 11 The signal （ One ） - Concept

background

Wikipedia has this definition of semaphore ：“ In computer science , Especially in the operating system , A semaphore is a variable or abstract data type , It is used to control the access of multiple processes to common resources in parallel programming or multi-user environment .” Semaphores are different from mutexes （ Or lock ）. Mutexes are most commonly used to manage access to a single resource by competing processes . When a resource has multiple copies of the same resource and each of these copies can be used simultaneously by a separate process , Will use semaphores .

Consider an office supply store . It may have several copiers for its customers , But each copier can only be used by one customer at a time . To control this , There is a set of keys that enable the machine and record its use . When a customer wants to copy a document , They asked the clerk for the key , Using machines , Then return the key , And pay royalties . If all the machines are in use , The customer must wait until the key is returned . Save the position of the key as a semaphore .

This example can be further extended to include different types of copiers , Perhaps they can be distinguished by the size of the copies they can make . under these circumstances , There will be multiple semaphores , If the replicator has any overlap in the size of the replication , Then customers who want to replicate a common size will have two resources to extract .

Introduce

Semaphores are shared objects , Used to provide fast... Between processes 、 Efficient communication . Each semaphore is a class %SYSTEM.Semaphore An example of . Semaphores can be modeled as a shared variable , It contains a 64 Bit nonnegative integer . An operation on a semaphore changes the value of a variable synchronously in all processes that share it . By convention , A change in value passes information between processes that share semaphores .

Although semaphores and locks seem to have a lot in common , But there are some advantages to using semaphores . One of the most important facts is , When semaphore is granted , Semaphores cause notifications to be sent . Therefore, a process using semaphores does not need to spend processor cycles or complex application logic polling the lock to check whether it has been released . Besides , The semaphore is in ECP Work transparently on the connection , And it is more efficient than the exchange required to check the lock in the same case .

Signal Overview

Signal name

Semaphores are identified by their names , These names are used as... When creating semaphores ObjectScript String provides . The names assigned to semaphores should conform to the rules of local and global variables . Semaphore names are only used to distinguish them from all other existing semaphores . Examples of valid name strings are ：SlotsOpen, J(3), ^pendingRequest(""j"").

Usually , Semaphores are stored on the instance that created the semaphore , And visible to all processes on the instance . however , When the semaphore name looks like the name of a global variable , Semaphores are stored in mapped global variables ( Include Subscripts ) On the system . This allows such a semaphore pair to ECP All processes running on instances of the system are visible .

Be careful ： The name of the semaphore is a string , But at run time, it can be controlled by such as "^" _ BaseName _ "(" _ (1 + 2) _ ")" Such an expression construct . If BaseName Include string “prters”, Then the semaphore name is ^prters(3).

Semaphore value

The semaphore value is stored as 63 Bit unsigned integer , Therefore, the semaphore value is always greater than or equal to zero .

maximal 63 Bit unsigned integer is 9,223,372,036,854,775,807((2**63)-1). Semaphores cannot be incremented beyond this value , Nor can it decrease below zero .

Semaphore instances and variables

Semaphores are derived from %SYSTEM.Semaphore Instance of class for . Once the semaphore is created and initialized , its OREF Usually stored in a Objectscript variable , So it can be used for other operations , Pass as a parameter , And finally deleted . Although the name of the variable containing the reference to the semaphore does not have to correspond to the name of the semaphore , But good programming habits indicate a relationship .

Like all object references to non persistent data , When the last semaphore reference is reclaimed , The underlying semaphore is also deleted .

Semaphore operation

Basics

Semaphore operations can be divided into two categories ： The operations of directly operating semaphores and waiting for other processes to operate semaphores . The first group includes ：

• Create – Create a new semaphore instance and initialize it for use
• Open —— Access and initialize existing semaphores
• Delete - Make it unavailable to any process that knows the semaphore
• Increment - Adds the specified quantity to the value of the semaphore
• Decrement —— If the semaphore value is zero , Then the operation waits for it to become positive . When the semaphore is positive , Subtract the decrement from the semaphore （ Or the value of the semaphore , Whichever is less ）.
• GetValue – Returns the current value of the semaphore
• SetValue – Set the current value of the semaphore to the non negative value provided

Manage multiple semaphores

The second set of operations involves managing the semaphore list as a group , And wait for each on The pending operation is completed ：

• AddToWaitMany – Add the given semaphore operation to the waiting list
• RemoveFromWaitMany – Deletes the specified semaphore operation from the wait list
• WaitMany – Wait for all semaphores in the wait list to complete their respective operations . This operation may time out .

Waiting queue

Each use WaitMany The process of coordinating multiple semaphores saves the semaphore decrement operation request in an internal list . The operation of the list is as follows ：

• When calling AddToWaitMany Method to place a decrement operation in the list , The system will try to decrement at this time . If the semaphore value is non-zero , Then the decline succeeds . The amount subtracted is the smaller of the semaphore value and the requested amount . Any request larger than the semaphore value will be forgotten .
• If the semaphore value is zero when the request is added to the list , Do nothing , And the request is considered pending . At some point in the future , If the target semaphore becomes non-zero , One of the processes will be selected , Its operation refers to the semaphore and performs its decrement operation . If the result of this operation is that the semaphore still has a non-zero value , The process will be repeated , Until there is no further request , Or the value of the semaphore becomes zero .
• When the process calls WaitMany When the method is used , Each operation in the wait list is checked . For satisfied requests , Call the... Of the target semaphore WaitComplete Method , Then delete the request from the waiting list . When it has processed all the satisfied requests , It returns the number of such requests to the caller ; If the wait timeout is exceeded , Then return to zero. . Pending and unsatisfied requests are still on the waiting list .
• Because of the asynchronous nature of semaphores , Calling WaitMany period , A pending request on the waiting list may be satisfied . At this time WaitMany Whether this satisfied request is counted during the call , Or whether it will be counted in subsequent calls , It's not sure yet .
• take OREF The process saved to the semaphore may also delete it . under these circumstances , What happens depends on whether the requested operation is satisfied .
  • If the semaphore is the target of the satisfied operation , Then mark the request as having decremented the semaphore by zero . Unable to call WaitComplete Method , Because the semaphore does not exist , However, the request is deemed to have been made in WaitMany The returned value is satisfied .
  • If the request is still pending , Then just delete it from the waiting list .

Callback

An instance of a semaphore inherits an abstract method WaitComplete, The user needs to implement this method . When processing requests that are satisfied on the waiting list ,WaitMany Call for each semaphore in the wait list WaitComplete Method , And the decreasing number of semaphores is passed as a parameter . When WaitComplete return ,WaitMany The request will be removed from the waiting list .

Other considerations

There are multiple decrement requests on the same wait list

It is not wrong to request decrement of the same semaphore multiple times in the same wait list . The added request processing method is as follows ：

• If the first request is not satisfied , Add the reduction of the second request to the reduction of the first request .
• If the first request has been satisfied ( In whole or in part ), The second request is processed normally . in other words , If the semaphore value is non-zero , The decrement request is fully or partially satisfied . however , The actual quantity subtracted is added to the quantity obtained by the first request .

Calling WaitMany Before , The decrement will not be reported through the callback , So multiple requests for the same semaphore look like a combined request . This can lead to the following ：

1. Semaphore A Set to 0.

2. Yes A Decrement request for 4.

3. Yes A The decrement request for is 1; New decrement = 5.

4. Semaphore A Set to 4.

5. Request satisfied ; 4 grant .

6. call waitmany ; Waiting for completion A The report .

7. Semaphore A Set to 1.

8. A Decrement request for , common 3 individual .

9. Request satisfied ; 1 grant .

10. Yes A Decrement request for 4.

11. call WaitMany; WaitCompleted for A The report 1.

12. Semaphore A Set to 1.

13. Yes A The decrement request for is 3.

14. Request satisfied ; 1 grant .

15. Yes A Decrement request for 4.

16. Semaphore A Set to 5.

17. Request satisfied ; 4 grant .

18. call WaitMany; WaitCompleted for A The report 5; Semaphore A value = 1.

Semaphore delete

Semaphores have no owner , And they are not referenced like object instances . Any process that can open a semaphore can delete it .

When a semaphore is deleted ,

1. If there is a pending decrement for this semaphore in any waiting list , Call WaitCompleted Callback , The decreasing value is zero .
2. It will be from the mapped system （ Local or remote ） Delete in .
3. Any further attempts by other processes to access it will fail , And appear <INVALID SEMAPHORE> error .

Work termination and waiting list

When the process terminates , Its waiting list is released . Remains in the waiting list but has not been by WaitMany Any satisfied decrement requests processed will be cleared . Their respective decrements are not added back to their decremented semaphores . Any unsatisfied requests in the waiting list will simply be deleted .

Semaphores and ECP

about ECP Semaphores on the system , Operations on semaphores are sorted according to the order in which requests reach the system holding the semaphore . Each operation is guaranteed to be completed before the next operation . The remote semaphore guarantees the following conditions ：

• Semaphore increase and decrease will occur in SET and KILL Later .
• When a semaphore is SET、 When increasing or decreasing ,ECP Data caching and subsequent on the server SET、 Increasing or decreasing is consistent .

Because semaphores are not persistent , So in case of service interruption ,ECP Pending semaphore operations across servers on the system are unrecoverable . Due to server or network failure ECP After interruption , Semaphores on the application server will be deleted , Pending requests on the data server will also be deleted . It is the responsibility of the application to detect this and recreate the required semaphores in the correct state .