Re: Synchronisation

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| Thinking more about Norm's dependency example, I realise I think we
| need to be _very_ modest in what we require in terms of guarantees of
| order of execution.  As an illustration, I propose a thought
| experiment about implementation -- suppose I am worried about
| deadlocks and buffering and all that, and so I take the simplest
| possible approach: I create a new thread for _every_ step in a
| pipeline, connect up the inputs and outputs, and start all the threads
| running simultaneously.  Is there anything in the spec. which rules
| this out?  I don't think so, and in fact I think it's a pretty good
| implementation strategy.

Precisely the one I have in mind, as it turns out :-)

| What follows from this is that if you have an out-of-band dependency,
| you _must_ either synchronise it oob, or use the writing of outputs
| and the reading of inputs to do so.
|
| So, that ends up being another argument against explicit step-on-step
| dependency annotations:  that would require my imaginery
| implementation to add an explicit thread management layer, where
| before the normal mechanisms of blocking for input would have done the
| job without any explicit control flow management at all.

Well, when I suggested it, I had in mind only that it would have the
same effect as wiring up a dummy output to an input that is never
read.

| I'm reminded of a point I've made before about pipelines --  they are
| _much_ easier to understand in terms of dataflow.  Adding a story
| about control flow just makes things messy -- I'm very loathe to go
| there just to allow side-effects to be synchronised.

I agree. I don't mind explicitly not going there, so long as we
thought about it and consciously agreed not to.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.