Source: https://www.adaic.org/resources/add_content/docs/95style/html/sec_6/6-1-3.html
Timestamp: 2019-04-18 18:31:30+00:00

Document:
Consider using discriminants to minimize the need for an explicit initialization operation (Rationale 1995, §9.1).
Consider using discriminants to control composite components of the protected objects, including setting the size of an entry family (Rationale 1995, §9.1).
Consider using a discriminant to set the priority of a protected object (Rationale 1995, §9.1).
Consider using a discriminant to identify an interrupt to a protected object (Rationale 1995, §9.1).
Using discriminants to parameterize protected objects provides a low-overhead way of specializing the protected object. You avoid having to declare and call special subprograms solely for the purpose of passing this information to the protected object.
Task discriminants provide a way for you to identify or parameterize a task without the overhead of an initial rendezvous. For example, you can use this discriminant to initialize a task or tell it who it is (from among an array of tasks) (Rationale 1995, §II.9). More importantly, you can associate the discriminant with specific data. When you use an access discriminant, you can bind the data securely to the task because the access discriminant is constant and cannot be detached from the task (Rationale 1995, §9.6). This reduces and might eliminate bottlenecks in the parallel activation of tasks (Rationale 1995, §9.6).
Using an access discriminant to initialize a task has a potential danger in that the data being referenced could change after the rendezvous. This possibility and its effects should be considered and, if necessary, appropriate actions taken (e.g., copy the referenced data and not rely on the data pointed to by the discriminant after initialization).

References: §9
 §9
 §9
 §9
 §9
 §9