Re: Looking for implementation idea

[Corey Minyard <minyard@acm.org>]

Thomas Handler <th@umundum.vol.at> writes:

> Hi everybody!
> 
> I'm trying to migrate a bundle of applications to Ada95 (running GNAT
> and Intel-Linux).
> The problem I'm suffering from at the moment is that most of the apps
> are heavy I/O bounded and the first one I'm gonna touch has to control
> typically around 100 devices via serial ports and about 40-50 socket
> connections.
> I already had implemented a raw draft of this app using C++ and did all
> of the work within a single process using select and having a state
> machine for each device and socket connection.
> 
> Anyway I saw that using C++ for a team of developers is rather
> problematic (yes I know many teams are using C++ but for me it's to
> unsafe - just my opinion, I prefer to sleep well during nights ;-) and
> so I convinced my boss to have a look on Ada95.

Wow, you must be very persuasive! :-)

Now about the tasking.

Since Ada has tasking built-in, there is a great temptation to use it
even when it is not the best way to solve the problem.  So I'm going
to have to jump on my tasking soapbox.

BEGIN SOAPBOX

I believe that tasking (or threading) is a heavily overused thing.
Not just in Ada, but generally.  IMHO, using tasking will have three
general effects on your system:

   1) It will be more complex

   2) It will be less efficient

   3) It will be less reliable

Now in more detail:

1) It will be more complex - Tasking can simplify the conceptual
   simplicity of a problem (just have each operation handled by one
   task, etc.).  However, that ignores the need for coordination of
   shared data access and inter-task interaction, which are much more
   complex in a tasking scenario.  It also makes recovery from
   overload much more difficult since the load is not in a centralized
   place.  Also, if the number of tasks is dynamic you will have to
   manage running out of tasking resources.

2) It will be less efficient - The overhead of context switches and
   inter-task communication are higher than just procecure calls.

3) It will be less reliable - Concurrency make the system more
   difficult to understand and test completely because of the
   asyncronous nature of the interactions.  It is easy to miss
   protecting a shared variable is impossible to test for.

So am I anti-tasking?  Not at all.  Tasking is an extremely important
concept in design of systems.  So why do I think tasking should be
used?

   1) Preemptability

   2) SMP Performance

   3) Performance using blocking I/O

   4) The OS doesn't support waiting for multiple things in one task

Again in more detail:

1) Preemptability - If an event occurs in the system and it must be
   handled in a timely fashion, tasking is the way to go.

2) SMP Performance - If you want to use all the processors in an SMP
   box for a single application, you will have to run multiple tasks.
   One per processor is often sufficient.  Note that this usually
   requires native threads, FSU threads won't give this.

3) Performance using blocking I/O - If your OS doesn't provide
   non-blocking reading or writing, you might have to use multiple
   tasks to improve the performance of your system, since the ability
   to have multiple I/O operation pending at the same time will
   improve the quality of disk scheduling and allows work to be done
   while waiting for I/O.  If the OS has non-blocking I/O, though,
   that is the way to go.

4) The OS doesn't support waiting for multiple things in one task -
   Some just don't (OS/2 comes to mind) and you have to have a task
   per input source.
   

So, for instance, in your system you might have multiple message
sources and message types with different priorities and in an overload
you might want to discard the lower-priority stuff before discarding
the higher priority.  You might also want to discard messages that are
older than a few seconds.

I would use multi-tasking in this design due to preemptability.  You
will need a higher-priority task reading input from the system and
managing queues to another task.  That task would enqueue messages,
discard old ones, and detect and manage an overload, so it would have
to be higher priority than the processing.  Another task would read
from the queues and process the items.  The only place of concurrency
here is the queues, which should be easy to manage.

If I had SMP, I might have one task per processor.  Then I have to
worry about concurrency between tasks if they update shared data.  But
that is the price to pay for using SMP.

Linux does have the ability to do non-blocking operations on the I/O
ports you are using and it can wait for multiple I/O operations at the
same time, so the other items are not a concern for you.

END SOAPBOX

Comments on this, of course, are welcome.  Hey, I am posting it to a
newgroup, what do I expect?

One question for the Ada experts: Ada protected types don't work in
SMP since they are task priority based, do they?  Or maybe I'm missing
something.  If they don't, maybe we should think about adding a real
semaphore to the Ada spec.

-- 
Corey Minyard                   Internet:  minyard@acm.org
  Work: minyard@nortelnetworks.com  UUCP:  minyard@wf-rch.cirr.com