protected var's

8.24: adda/concurrency/protected var's:

. how do protected var's work?

it is an obj' shared by multiple processes

enforcing mutex (mutual exclusion) by a service request queue

(conceptually if not practically);

one process doesn't get to start a job until

any other processes have had their job finished .

. there is a serialization factor:

. after an access has been made,

the accessing process expects the change to be recognized;

ie, after being allowed to make the access,

any other transactions it makes with other processes or external var's

are assumed to be under the influence of that change .

. if the protected var' can't finish the job,

then it needs to raise an exception

(replying to service request with a reason for failure

instead of the expected result);

and if that process doesn't have a handler (for that exception),

then the exception propagates up to that process`parent.process; etc,

and possibly up to the user,

explaining what sort of bug there is:

the entire program is allowing a component failure

(by not catching these exceptions)

which may compromise the output quality .

. it needs to have a time-out in case it freezes:

if there is a long wait (eg, 1/10 sec),

then the run.time mgt would check to see if it's waiting on resources;

if not, then it may be frozen .

. there should be a way for the programmer

to communicate that a freeze has not occured .

. this would be similar to the way a user-friendly program

will use a progress meter to show the amount of work to be done .

. if it doesn't know the workload size,

it should give a pointer to the place where it is getting the work .

(assuming the users may know more about the potential size of a source

if they know source's full pathname) .

. in addition to accessor operators,

protected var's can have [/]entries .

. while accessors are alway synchronous,

entries can be done either sync'ly or async'ly .

[this departs from ada's definition of protected var] .

. synchronous messages are like subroutine calls:

the calling process waits for the call to finish

before going on with the rest of its routine .

. asynchronous messages are like message machines:

letting the caller drop off a service request

and then continue without waiting for a response .

. the requested service either has nothing to return,

or has the return assigned to another protected var':

one that doesn't allow access until the assignment is done .

[12.19: todo:

full implications of this aren't clear;

very important that async' is carefully proofed;

since this is what can make concurrency tricky .

]

. {out, inout}.mode parameters are also returns;

so then, if a process is blocked,

it could be trying to access variables that are

waiting for an async'entry's return .

(if the lang allows streaming out.mode param's,

then a stream must be able to receive an [end of stream].signal ) .

. the run-time mgt, perhaps through the scheduler,

should be keeping track of a process's pending async'service returns .

. the {service provider, protected var} has a lock on

all the var's being targeted for the returns,

so the scheduler is urged to prioritize the

{message, process owning the service request}

in order to avoid causing the caller to block .

. when a block does occur,

the scheduler must know that unblocking

depends on that job finishing,

or returning an exception instead (indicating the job failed) .

. designers using async' messaging

should keep in mind that if any of the caller's future processing

depends on the job being processed,

then the entry should be designed with some output param';

and then that output will tell the caller

when the job was processed .

. the accessor operators of the protected var'

are expected to be brief;

but, assuming they are not,

the protected var's become bottlenecks for the concurrency:

. any process using an accessor has to be suspended

until that accessor job is finished .

. the scheduler's time-slicing tree is being rearranged

so that protected var's that are becoming

bottlenecks to concurrency

must be given priority equal to that of its caller`process .