When a transputer sets its lock flag (see section 4 on the Statusregisters) an access to VME will lock the VME-bus for exclusive access by this transputer. It can then e.g. simulate Read-Modify-Write cycles or Block Transfers in VME (provided the VME-slave is capable of handling Block Transfer: it must increment the VME-address locally). Because access to VME-bus is denied to other masters during and after these cycles it is important that the lock flag is reset as soon as possible.
Note on the use of the lock flag: the user should be aware of the fact that a transputer process might be descheduled at a jump instruction, timer input or channel communication, or - if it is a low priority process - at any location in the program if a high priority process is ready to run. The result might be that the process that set the lock flag and locked the busses is descheduled before it has reset it again and is only rescheduled again after one or more process timeslices or until the high priority process is descheduled. Any other 2TP-VME transputer wanting to access the VME-bus during this period might have its attempted VME-cycle aborted and its refresh timeout error flag timeout set because it can not get access to the bus which is locked by the descheduled process.
Thus the user must pay attention to his use of high priority processes and should never put code in between lock set and reset that results in jump-, timerinput-, or channel-communication-instructions if other transputers or processes also make use of the bus.