Re: multiple delay alternative

[Robert Eachus <rieachus@comcast.net>]

On Monday, March 5, 2018 at 8:50:51 PM UTC-5, Mehdi Saada wrote:

> Before that, one thing I can't get, even after asking other people:
> for protected objects, in a protected procedure, when it's blocked, because a reading (protected function) or an entry is being served, are the calls to the procedure put on a queue as with entries ?
> Someone said me the advantage of protected procedures was that you don't have to wait, but I read also they were exclusive with each others... damn.

If a task calls an entry of a protected object, and has to wait, it waits, if you will, before the entry.  You can use select statements to wait, or even abandon the entry call immediately.  For subprograms of a protected object, the call is evaluated immediately, even if the protected object is busy.  Then procedure calls are executed sequentially.  After each protected action the entry queues are checked.  If a protected function call is active, all waiting function calls (again parameters evaluated immediately) are executed simultaneously before the entry queues are again checked.

Randy, is this right for the default rules?  I never bother because 9.5.1 (8..18) and the following notes mean I need to get the behavior right for well spaced calls, and the implementation will sort races however they fall out.  In other words, I can't really tell what order things happen in the case of truly simultaneous calls from different tasks--and CPU cores.  All I get is that the invariants and pre- and post- conditions hold.

The invariants are:

1) Only one entry or externally called procedure can be active at any point in time.
2) An entry or externally called procedure can call (internally) other procedures or functions without blocking.
3) If an externally called function is active, many other function calls can (in theory) be active, but no procedure or entry calls.
4) The state of the protected object (internal variables) cannot be changed by a function call.  However, local variables in the function can change, for example the index of a loop statement.

If you want to design complex protected objects, another important point/gotcha is that "potentially blocking" actions shouldn't occur within the protected body.  That effectively limits you to fairly standard synchronizing constructs.  The examples at the bottom of 9.4 are a good place to start.