The resulting semaphore is then stored in a lock table local to the workstation. This is done for several reasons.
First, OpenInsight supports the capability for programmers to attempt multiple locks on the same record. In trapping these locks locally, the system reduces lock overhead by avoiding extra lock calls made to the network. If a record is already locked by the local station, this can be detected without an additional call to the network.
Second, storing locks locally gives OpenInsight the ability to report that a lock has already been set by that station. (This is done by testing STATUS( ) after a lock has failed.) Some networks do not permit a station to lock the same record twice, and do not report back the proper error condition.
Finally, the hashing scheme OpenInsight uses to create the semaphores allows the possibility that entirely different file and record combinations can produce the same semaphore. By maintaining a local lock table, OpenInsight can detect this and arbitrate conflicts arising from duplicate semaphores.
Only non-duplicated semaphores are passed through to the filing system.
A lock is thus processed at two levels. The first is within the system before a call is made to the filing system. Only after the internal lock table has been examined -- and only if necessary -- is the lock call passed through to the MFS.
As a result, not all lock calls can be trapped at the MFS level. For example, if a station has a record locked, and attempts to lock it again from a different program or level of execution, the MFS will never receive a lock call. Instead, the system will have already detected a conflict based on the local lock table, and will have returned the proper response to BASIC+.
The same is true of unlock calls. If the system can resolve an unlock call by referencing only the local lock table, it will do so. In these cases, as with the lock calls, the MFS will never receive the unlock call.
If the lock or unlock call does pass through to the MFS and down to the BFS, the filing system will return information about the lock and its status.
| Lock information returned by the BFS should never be altered by an MFS, as it will be stored in the local lock table, and be used to coordinate with other locks. |