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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,98fcd569e727e97c X-Google-Attributes: gid103376,public From: "Samuel A. Mize" Subject: Re: Tasking Techniques - Opinions? Date: 1997/06/04 Message-ID: <3395A448.41C6@magellan.bgm.link.com>#1/1 X-Deja-AN: 246097718 References: <5n2hjr$ohm$1@news.pacifier.com> <3394ecbe.215389049@news.pcisys.net> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-06-04T00:00:00+00:00 List-Id: bsanden@acm.org wrote: > On 4 Jun 1997 01:49:47 GMT, steved@pacifier.com (Steve Doiel) wrote: ... > >In the current implementation, one module maintains a free pool > >of packet buffers. Access to the free pool is done using a > >protected type. A second module contains a protected type that > >contains a FIFO of packet buffers (the send queue). A third > >module contains a "send task" that is in a short loop that > >removes entries from the send queue, transmits the data out the > >socket and then returns the packet buffer to the free pool. ... > Sounds perfectly reasonable to me. Ada 83 forced many more tasks into > the designs than were actually justified by real concurrency. The > protected objects have made this much more palatable. Letting tasks > communicate via shared objects is also the traditional way of doing > these things. Absolutely true. However, do be aware that protected types have significant overhead -- not as much as task rendezvous, but on the order of ten times a procedure call. If speed is of the essence, AND protected objects are slowing your system too much, you may need to look at "atomic" variables (see pragma Atomic). For instance, a circular buffer using a reader and a writer index, where each task needs only read access to the other's index. The issues to address in this case: 1 Protected objects give you easy concurrency protection. Home-rolled concurrency protection is hard to get totally right. 2 If one task has to wait for the other -- for instance,if the circular buffer is full so the writer has to wait -- you have to determine how to make it wait (or do something else for a while), and how to make sure that the other task gets a chance to run and consume something from the buffer. You get that for free with protected entries. 3 Depending on your compiler/implementation, atomic variables may take almost as much time as protected. Do some timing tests. Point 1 is the big motivator. Getting concurrency totally right is really really hard. So, in general, use protected objects. If speed is critical AND protected objects are slowing it down too much, AND atomic variables are faster on your system, consider a more-traditional shared-data approach using atomic objects. Sam Mize -- -- Samuel Mize (817) 619-8622 "Team Ada" -- Hughes Training Inc. PO Box 6171 m/s 400, Arlington TX 76005