☜ | ABLOCKDraft MDC Standard | ☞ |
AB[LOCK] postcond | │ │ │ |
[ SP ] SP ablockargument |
│ │ │ |
Editor’s note: The above definition allows for at most one ablockargument. Should it not be:
|
ablockargument | ::= | │ │ │ |
L evclass ( L evclass ) |
│ │ │ |
evclass | ::= | expr V | " | │ │ │ │ │ │ │ │ |
COMM IPC INTERRUPT POWER TIMER USER Z[unspecified] |
│ │ │ │ │ │ │ │ |
" |
Event classes not specified above are reserved for future extensions to the standard.
ABlock temporarily blocks events during critical sections of a process. The three forms of ABlock are given the following names:
a) | L evclass | Selective ABlock | ||
b) | (L evclass) | Exclusive ABlock | ||
c) | Empty argument list: | ABlock All |
In the Selective ABlock, the named event classes are blocked as described below. In the Exclusive ABlock, all event classes except the named event classes are blocked as described below. In the ABlock All, all event classes are blocked as described below.
When an event class is blocked, an internal counter for that event class is incremented. If the counter has a positive value, all events of that class are blocked from interrupting the process executing the ABlock command. If a registered event occurs while blocked, the event is queued. Unregistered events are not queued. Additional subsequent events may be queued if space is provided by the implementation (space for only one event is guaranteed). Events, if queued, will occur in the order in which they occurred when the block is removed (i.e., when the counter becomes zero). All events for a process are stored in one of two queues (one for synchronous events, the other for asynchronous events), rather than a separate queue for each class. Each process, however, must maintain its own queues, as each process blocks and unblocks events independently.
Copyright © Standard Documents; 1977-2024 MUMPS Development Committee;
Copyright © Examples: 1995-2024 Ed de Moel;
Copyright © Annotations: 2003-2008 Jacquard Systems Research
Copyright © Annotations: 2008-2024 Ed de Moel.
Some specifications are "approved for inclusion in a future standard". Note that the MUMPS Development Committee cannot guarantee that such future standards will indeed be published.
This page most recently updated on 15-Nov-2023, 13:21:39.
For comments, contact Ed de Moel (demoel@jacquardsystems.com)