4D v13.4Semaphore |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4D v13.4
Semaphore
Semaphore
A semaphore is a flag shared among workstations (each user’s computer) or among processes on the same workstation. A semaphore simply exists or does not exist. The methods that each user is running can test for the existence of a semaphore. By creating and testing semaphores, methods can communicate between workstations. The Semaphore function returns TRUE and does nothing if semaphore already exists. If semaphore does not exist, Semaphore creates it and returns FALSE. Only one user at a time can create a semaphore. If Semaphore returns FALSE, it means that the semaphore did not exist, but it also means that the semaphore has been set for the process in which the call has been made. Semaphore returns FALSE if the semaphore was not set. It also returns FALSE if the semaphore is already set by the same process in which the call has been made. semaphore is limited to 255 characters, including prefixes (<>, $). If you pass a longer string, the semaphore will be tested with the truncated string. The optional parameter tickCount allows you to specify a waiting time (in ticks) if semaphore is already set. In this case, the function will wait either for the semaphore to be freed or the waiting time to expire before returning True. There are two types of semaphores in 4D: local semaphores and global semaphores.
Global and local semaphores are identical in their logic. The difference resides in their scope. In client-server mode, global semaphores are shared among all the processes running on all clients and servers. A local semaphore is only shared among the processes running on the machine where it has been created. In 4D, global or local semaphores have the same scope because you are the only user. However, if your database is being used in both setups, make sure to use global or local semaphores depending on what you want to do. Note: We recommend using local semaphores when you need a semaphore to manage a local aspect for a client of the application, such as the interface or an array of interprocess variables. If you use a global semaphores in this case, it would not only cause unnecessary network exchanges but could also affect other client machines unnecessarily. Using a local semaphore would avoid these undesirable side effects. You do not use semaphores to protect record access. This is automatically done by 4D and 4D Server. Use semaphores to prevent several users from performing the same operation at the same time. In this example, you want to prevent two users from doing a global update of the prices in a Products table. The following method uses semaphores to manage this: If(Semaphore("UpdatePrices")) ` Try to create the semaphore The following example uses a local semaphore. In a database with several processes, you want to maintain a To Do list. You want to maintain the list in an interprocess array and not in a table. You use a semaphore to prevent simultaneous access. In this situation, you only need to use a local semaphore, because your To Do list is only for your use. The interprocess array is initialized in the Startup method: ARRAY TEXT(◊ToDoList;0) ` The To Do list is initially empty Here is the method used for adding items to the To Do list: ` ADD TO DO LIST project method You can call the above method from any process. This method allows you to not execute a method when a semaphore is present; the method alerts the calling method with an error code and plain text. Syntax: $L_Error:=Semaphore_proof(->$T_Text_error) // Protective structure using semaphores |
PROPERTIES
Product: 4D
INDEX HISTORY
Modified: 4D v11 SQL SEE ALSO
CLEAR SEMAPHORE |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||