Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 21 Oct 2005 01:26:36 +0200

On Tuesday 18 October 2005 15:22, Marty Kraimer wrote:
> I am concerned about how complex it will be to implement something
> like what Benjamin is proposing.
>
> The original proposal uses "block" to mean no further record
> processing until this link and all previous links complete.
> Bemjamin's proposal uses "after" to mean the this link (or something
> more generic) should not be processed until a list of other links (or
> something more generic) completes.
> [...]
> Maintaining after lists sounds complex to implement. 

Ok, let me sketch a possible implementation. Let X be some field of a 
record R that can be 'processed' and might send some notification after 
completion (for example a link field).

Let Y be another field of R that denotes some action to be done during 
processing of the record (for example another link field; or a field 
denoting record process completion). For each such field the record 
contains an array or a list of field identifiers (pointers or indices) 
on whose completion execution of step Y depends (specified by its 
attribute 'after' (or whatever it will be called in the end)).

As soon as the record undertakes to execute the processing step denoted 
by Y, it 'blocks'. Well, what it really does is return control to the 
core library, indicating the desired step (for instance by setting a 
special field). The core now checks if all conditions are fulfilled 
(i.e. all Xs on which Y needs to wait have completed), and in this case 
control is returned immediately to the record. Otherwise the record is 
put on a wait list. Whenever some X completes, it calls a core routine 
that sets its completion flag and then looks up(*) the list belonging 
to field Y of record R to check if now all conditions are fulfilled. If 
yes it wakes up some task that will proceed processing the record.

Many variations of this scheme are possible, of course. For instance, 
bitmasks could be used instead of arrays or lists to store the 
completion flags that a record waits for. All in all, it looks to me as 
if the proposal could be implemented without undue overhead.

> Is it more 
> intuitive for the database developer? Not clear to me.

Well, the approach I proposed is obviously more declarative in nature 
which some may find less intuitive. OTOH, the semantics is very simple 
and easy to understand. It is also explicit and unambigous about all 
processing/completion dependencies. I would think that this will become 
an advantage in the long run i.e. when it comes to maintainability; but 
again, others may have a different opinion.

Cheers,
Ben

(*) This lookup is cheap, it is merely a double indirection. The check 
itself is linear in the number of completions to be waited for.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System