Bound program access |
---|
|
The LOCKTSL instruction can be used to lock space locations including teraspace storage locations. The locks identified in the lock request template (operand 1) are requested by the current thread. By default, these locks are obtained thread scoped. Process and transaction control structure scoped locks are also supported for non-teraspace storage locations. A maximum of 4093 space locations can be locked with one LOCKTSL instruction.
Only the thread which is performing the lock operation and any other threads in the same process will ever conflict on teraspace storage location locks.
Locking a teraspace storage location does not prevent any byte operation from referencing that location, nor does it prevent the space from being extended, truncated, or destroyed. Teraspace storage location locks follow the normal locking rules with respect to conflicts and waits.
The lock request template identified by operand 1 must be aligned on a 16-byte boundary or an boundary alignment (hex 0602) exception is signaled. The format of operand 1 is as follows:
Offset | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Dec | Hex |
| Field Name |
| Data Type and Length | ||||||||||||
0 | 0 |
| Number of lock requests in the template (max 4093) |
| UBin(4) | ||||||||||||
4 | 4 |
| Offset to lock state selection values |
| UBin(2) | ||||||||||||
6 | 6 |
| Wait time-out value for instruction |
| Char(8) | ||||||||||||
14 | E |
| Lock request options |
| Char(3) | ||||||||||||
14 | E |
| Reserved (binary 0) |
| Bit 0 | ||||||||||||
14 | E |
| Lock request type |
| Bit 1 | ||||||||||||
|
|
|
| ||||||||||||||
14 | E |
| Access state modifications |
| Bits 2-3 | ||||||||||||
14 | E |
| When the process is entering lock wait for synchronous request: |
| Bit 2 | ||||||||||||
|
|
|
| ||||||||||||||
14 | E |
| When the process is leaving lock wait for synchronous request: |
| Bit 3 | ||||||||||||
|
|
|
| ||||||||||||||
14 | E |
| Obsolete |
| Bit 4 | ||||||||||||
14 | E |
| Reserved (binary 0) |
| Bit 5 | ||||||||||||
14 | E |
| Time-out option |
| Bit 6 | ||||||||||||
|
|
|
| ||||||||||||||
14 | E |
| Reserved (binary 0) |
| Bit 7 | ||||||||||||
14 | E |
| Lock scope |
| Bit 8 | ||||||||||||
|
|
|
| ||||||||||||||
14 | E |
| Lock scope object type |
| Bit 9 | ||||||||||||
|
|
|
| ||||||||||||||
14 | E |
| Reserved (binary 0) |
| Bits 10-15 | ||||||||||||
14 | E |
| Modify thread event mask option |
| Bit 16 | ||||||||||||
|
|
|
| ||||||||||||||
14 | E |
| Asynchronous signals processing option |
| Bit 17 | ||||||||||||
|
|
|
| ||||||||||||||
14 | E |
| Reserved (binary 0) |
| Bits 18-23 | ||||||||||||
17 | 11 |
| Modify thread event mask control |
| Char(4) | ||||||||||||
17 | 11 |
| New thread event mask |
| UBin(2) | ||||||||||||
19 | 13 |
| Previous thread event mask |
| UBin(2) | ||||||||||||
21 | 15 |
| Reserved (binary 0) |
| Char(11) | ||||||||||||
32 | 20 |
| Location(s) to be locked |
| [*] Space pointer | ||||||||||||
|
|
|
(This should be repeated as specified by number of
lock requests in the template above.)
| ||||||||||||||
* | * |
| --- End --- |
|
|
The lock state selection is located by adding the offset to
lock state selection values above to operand 1.
Offset | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Dec | Hex |
| Field Name |
| Data Type and Length | ||||||||||||
0 | 0 |
| Lock state selection |
| [*] Char(1) | ||||||||||||
|
|
|
(repeated for each pointer in the template)
| ||||||||||||||
0 | 0 |
| Requested lock state |
| Bits 0-4 | ||||||||||||
|
|
|
(1 = lock requested, 0 = lock not requested)
Only one state may be requested per entry.
| ||||||||||||||
0 | 0 |
| LSRD lock |
| Bit 0 | ||||||||||||
0 | 0 |
| LSRO lock |
| Bit 1 | ||||||||||||
0 | 0 |
| LSUP lock |
| Bit 2 | ||||||||||||
0 | 0 |
| LEAR lock |
| Bit 3 | ||||||||||||
0 | 0 |
| LENR lock |
| Bit 4 | ||||||||||||
0 | 0 |
| Reserved (binary 0) |
| Bits 5-6 | ||||||||||||
0 | 0 |
| Entry active indicator |
| Bit 7 | ||||||||||||
|
|
|
| ||||||||||||||
* | * |
| --- End --- |
|
|
A single Lock Teraspace Storage Location instruction can request the allocation of one or more lock states on one or more storage locations. The locks are granted sequentially until all the locks requested are granted.
Note that when locks are materialized using Materialize Process Locks, (MATPRLK), if the process whose locks are being materialized is not the current process, then a null pointer value is returned for any lock on a teraspace storage location. If the current process is materializing its own locks, then a space pointer to the teraspace is generated when the lock was acquired.
The wait time-out value for instruction field establishes the maximum amount of time that a thread competes for the requested set of locks when the lock request type is synchronous. See Standard Time Format for additional information on the format of the wait time-out value for instruction field. The maximum wait time-out interval allowed is a value equal to (2 48 - 1) microseconds. Any value that indicates more time than the maximum wait time-out interval causes the maximum wait time-out interval to be used. If the wait time-out value for instruction field is set to a value of binary 0, then the value associated with the default wait time-out parameter in the process definition template is used.
When a requested lock state cannot be immediately granted, any locks already granted by this Lock Teraspace Storage Location instruction are released and the lock request type specified in the lock request template establishes the machine action. The lock request type values are described in the following paragraphs.
When:
If the lock request type is synchronous and the invocation containing the Lock Teraspace Storage Location instruction is terminated, then the lock request is canceled.
Allocated space location locks are removed when the thread holding the locks terminates. If a thread terminates while waiting for a teraspace storage location lock, the lock request is canceled.
The lock scope field and the lock scope object type field determine which scope all specified lock requests will be allocated to: a thread, a process or a transaction control structure.
Note: Teraspace locations can only be scoped to the current thread, otherwise the template value invalid (hex 3801) exception will be signaled.
Locks scoped to a thread with a lock space object type value of process containing the current thread can never conflict with a lock scoped to its containing process, but may conflict with a lock scoped to a different process, a transaction control structure, or any other thread (depending on the lock states involved). Locks scoped to a thread with a lock space object type value of transaction control structure attached to the current thread can never conflict with a lock scoped to the transaction control structure, but may conflict with a lock scoped to a different transaction control structure, a process, or any other thread (depending on the lock states involved).
If lock scope object type has a value of transaction control structure attached to the current thread and the transaction control structure state does not allow objects to be locked on behalf of the transaction control structure, a object not eligible for operation (hex 2204) exception is signaled.
Allocated process scoped locks and any thread scoped locks, allocated by the initial thread of the process, are released when the initial thread terminates. Allocated thread scoped locks are released when the thread terminates. If a thread requested a process scoped lock, the process will continue to hold that lock after termination of the requesting thread. If a thread requested a transaction control structure scoped lock, the transaction control structure will continue to hold that lock after the termination of the requesting thread.
The modify thread event mask option controls the state of the event mask in the thread executing this instruction. When the thread event mask is in the masked state, the machine does not schedule signaled event monitors in the thread. The event monitors continue to be signaled by the machine or other threads. When the thread event mask is modified to the unmasked state, event handlers are scheduled to handle those events that occurred while the thread was masked and those events occurring while in the unmasked state.
If the system security level machine attribute is hex 40 or greater and the thread is running in user state, then the modify thread event mask option is not allowed and a template value invalid (hex 3801) exception is signalled.
When the modify thread event mask is set to 1, the previous thread event mask will be returned and the new thread event mask will take effect only when lock(s) have been successfully granted. If the lock request is not successful, the previous thread event mask value is not returned, nor does the new thread event mask take effect.
The thread event mask values are validity checked only when the modify thread event mask is set to 1, and ignored otherwise. Valid masking values are:
0 | Masked |
256 | Unmasked |
Other values are reserved and must not be specified, otherwise a template value invalid (hex 3801) exception is signaled.
The asynchronous signals processing option controls the action to be taken if an asynchronous signal is pending or received while in lock wait. If an asynchronous signal that is not blocked or ignored is generated for the thread and the asynchronous signals processing option indicates allow asynchronous signals processing during Lock Teraspace Storage Location wait, the Lock Teraspace Storage Location wait will be terminated and an asynchronous signal terminated MI wait (hex 4C01) exception is signaled. Otherwise, when the asynchronous signals processing option indicates do not allow asynchronous signals processing during Lock Teraspace Storage Location wait, the thread remains in the wait until all requested locks can be granted or until the wait time-out value for instruction expires.
If any exception is identified during the instruction's execution, any locks already granted by the instruction are released, and the lock request is canceled.
For each lock, counts are kept by lock state and by thread. When a lock request is granted, the appropriate lock count of each lock state specified is incremented by 1.
06 Addressing
08 Argument/Parameter
10 Damage Encountered
1A Lock State
1C Machine-Dependent
20 Machine Support
22 Object Access
24 Pointer Specification
2E Resource Control Limit
36 Space Management
38 Template Specification
3A Wait Time-Out
44 Protection Violation
4C Signals Management