Re: lines of code?

From: Chris Smith (cdsmith_at_twu.net)
Date: 12/11/03 

Date: Thu, 11 Dec 2003 05:38:43 -0700

Hi goose,

Thanks for your reply. If you don't mind, I'm going to simplify your
response by eliminating the part about embedded systems. That seems to
be your area, and the same ideas apply in either case... but I'm
guessing that for the majority of the readership, high-level libraries
such as UNIX select() and other means of async I/O are going to be the
way to go.

goose wrote:
> Your "alternative" to multiple threads is to "jump back and forth
> from one task to another [in] the same thread". I'd suggest that
> if your /solution/ demands multiple threads and/or tasks, then go
> ahead and use it, but dont try to implement a multiple-thread
> solution in a single thread. that just wont work nicely.

Just to clarify, we are talking about whether multithreading is ever
justified on a uniprocessor, right? That's what I thought we're talking
about. It sounds like you're saying that I should use multiple threads
on a uniprocessor in some cases. If you're saying that, then perhaps I
just imagined the difference of opinion in the first place.
Nevertheless, you later said:

> in a server environment, lets say a unix machine of some sort
> (or even windows nt or better), you want to read from the
> network *and* do user input ? no problem, use select() to read
> from the network;

That's making some assumptions about the problem that I was careful not
to make. Specifically, the goals I meant to discuss were intended to be
sufficiently involved as to require some degree of complex state on the
stack. I further intended that there be two fairly "live" goals
involved (and you'll notice that I mean something like "real-time", but
I'm being careful not to say real-time because I don't want to imply the
kind of substantial penalties for delay that are a connotation of that
term). So no, I'm not saying that threads are required every time a
network connection is used in an application.

Here's a very specific example:

Let's say I've got an application that reads some kind of TCP-based
streaming video protocol from one incoming network connection, performs
a transformation on it, and streams the resulting video out another
network connection. Both streaming protocols are rather involved,
requiring context-sensitive back-and-forth between client and server to
negotiate the data transfer rate and video characteristics required, and
the implementation of such a server ends up involving multiple levels of
recursion. The transformation itself may be simple, but the application
then has to implement the same very involved streaming video protocol
(from the other side) to retransmit the transformed data.

The problem with using select is this: every time you call select, it
might give you any amount of data in either direction. So you read
enough data to get seven deep in function calls in the streaming client
code, and then run out of available data. However, you *do* have a
frame available now to transmit to your *own* client, and you were also
waiting for available space in the buffer to do so. That space is now
available. Implementing the protocol to transmit that frame to the
client now is going to leave you five function calls deep in the
streaming server code. At that point, you want to return to receiving
data from your own source. How do you do that?

The only reasonable answer is that you rewrite those trasmit and receive
libraries so that they don't make function calls that will take time.
That means that you move their use of recursion to use of an explicitly
managed external stack, in conjunction with some kind of a deterministic
state machine to manage the protocol. Now, that's not a desirable
outcome: given a choice, most people would far rather read and
understand a top-down implementation of a context-ful network protocol
than a (state machine + external data) implementation. You are being
forced into the latter case by your choice to avoid multiple threads.

> however my rant was about coming up with a solution that involves
> multiple threads merely because the environment offers it.

Yet you continued to disagree when Michael and I both pointed out that
there are legitimate reasons for multithreading on a uniprocessor. Do
you agree with these legitimate reasons, or not?

Of course, in embedded systems, interrupts solve *some* of this problem,
exactly because they provide the ability to do some of what threads do:
interrupt an involved task, saving its entire state, and go do something
else. Even there, though, if the task to be done on the basis of the
interrupt is also involved and stateful, you run into problems because
the stack for the interrupt context is generally not preserved; so you
can deal with one stateful task + one interactive (non-batch) task, but
two tasks that are *both* stateful and interactive is still beyond you
without resorting to jmping through hoops to move the entire state off
of the program stack.

> the idea is not to squeeze every last bit of performance out of the
> system, but to make it easier and simpler to understand. a single
> thread of execution is *always* easier to read and then draw a diagram
> off, especially if the code is all new to you.

Reading the above, do you still agree? Is it really easier to
understand a single-threaded program that implements complex network
protocols as deterministic state machines? I would find that hard to
believe. 

-- 
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Relevant Pages

  • Re: lines of code?
    ... network connection is used in an application. ... streaming video protocol from one incoming network connection, ... Both streaming protocols are rather involved, ... than a (state machine + external data) implementation. ...
    (comp.programming)
  • Re: Up- and Downstreaming of Windows Media Objects
    ... UDP is just a trasport, over which RTP, a real streaming ... protocol is built. ... you need a streaming server. ... If you are willing to use WMS9 on Win2K3+, ...
    (microsoft.public.windowsmedia.sdk)
  • Re: C00D11BB Streaming Error
    ... that was just an aside about how XP vs Vista protocol issues actually ... See http://zachd.com/pss/pss.html for some helpful WMP info. ... and play same radio station in IE based WMP control. ... Server and doesn't have HTTP Streaming enabled, ...
    (microsoft.public.windowsmedia.player)
  • Re: Media Player 11 & mms streaming problem
    ... If WMP11 for XP does not support mms, then we need to use rtsp. ... protocol as well as a rollover protocol moniker. ... As a streaming protocol ...
    (microsoft.public.windowsmedia.server)
  • Re: O-O and OSI layers?
    ... > facilities within layers. ... So it depends on what your colleague was ... I'm absolutely sure a lot of protocol implementation has been done ... The object state machine for TCP ...
    (comp.object)