From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,956e1c708fea1c33 X-Google-Attributes: gid103376,public From: Corey Minyard Subject: Re: Looking for implementation idea Date: 1999/02/07 Message-ID: X-Deja-AN: 441723937 Sender: minyard@wf-rch.cirr.com References: <36BD749B.DA735DB7@umundum.vol.at> Organization: Wonderforce Research Reply-To: minyard@acm.org Newsgroups: comp.lang.ada Date: 1999-02-07T00:00:00+00:00 List-Id: Thomas Handler 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