Standards Update, IEEE 1003.4: Real-time Extensions

[Henry Spencer]

Submitted-by: henry at zoo.toronto.edu (Henry Spencer)

In article <544 at usenix.ORG> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>> Programs that want to do two things at once should use explicit parallelism,
>> e.g. some sort of threads facility.  In every case I've seen, this yielded
>> vastly superior code, with clearer structure and better error handling.
>
>I agree that programs that want to do two things at once should use
>threads. However, a program that sends out several connection requests
>is *not*, in fact, doing several things at once...

I'm afraid I don't understand:  a program that is trying, simultaneously,
to open several different connections is somehow not doing several things
at once?  I think this is a confusion of implementation with specification.

The program *is* doing several things at once, to wit opening several
connections at once.  If "open" is split into several steps, you can
implement this in a single-threaded program, crudely, by interleaving
the steps of the different opens.  My point is that the code is cleaner,
and often details like good error handling are easier, if you admit that
there is parallel activity here and use explicitly parallel constructs.
Then an "open" that is ready for step 2 does not need to wait for all
the others to finish step 1 first.  And if you do this, there is no need
to decompose "open" at all, because each thread just does all the steps
of one open in sequence.  Furthermore, it can then proceed to do other
useful setup chores, e.g. initial dialog on its connection, without
waiting for the others.  This is a far more natural model of what's
going on than forcing everything into one sequential process, and a
much better match for the semantics of the problem.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry at zoo.toronto.edu   utzoo!henry

Volume-Number: Volume 21, Number 134