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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ec570d1a83fda83c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-27 05:51:08 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!nycmny1-snh1.gtei.net!chcgil2-snf1.gtei.net!news.gtei.net!news.huji.ac.il!not-for-mail From: "Ehud Lamm" Newsgroups: comp.lang.ada Subject: Re: Problem with tasks Date: Fri, 27 Jul 2001 15:42:36 +0300 Organization: The Hebrew University of Jerusalem Message-ID: <9jrnld$ki$1@news.huji.ac.il> References: <3b5e887e.10671695@news.bt.es> <9jpujh$158$1@news.huji.ac.il> NNTP-Posting-Host: di3-75.dialin.huji.ac.il X-Trace: news.huji.ac.il 996237806 658 132.64.13.75 (27 Jul 2001 12:43:26 GMT) X-Complaints-To: abuse@news.huji.ac.il NNTP-Posting-Date: Fri, 27 Jul 2001 12:43:26 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Xref: archiver1.google.com comp.lang.ada:10633 Date: 2001-07-27T15:42:36+03:00 List-Id: > Right. That's why a good design would make use of a task-allocator > abstraction, which may allocate a new taks, but may later be changed to > manage a finite sized pool of tasks (the "thread pool" pattern). > Creating such a task allocator (or manager) abstraction is far from trivial. Some difficulties stem from Ada's apporach to tasking. Ada tasks types are not polymorphic, in the sense of allowing you create code that accepts any tasks supporting a given interface. In Ada95 we can solve this problem by vreating a tagged type that encapsualtes the task: All task type that support a given interface will simply derive from this type, allowing us to code class-wide routines, store them in heterogenous structures etc. (This approach has some problem. Using this approach we will not call task entries directly, but rather by using a wrapper routine. The excludes the possibility of timed-entry calls etc. This approach is also rather cumbersome and verbose). Another related issue is that tasks in this scheme must all behave along similar lines (e.g., they usually all have to be server tasks accepting work inside a loop. Exit/Restart entries may be needed, esp. if you want to support resing existing tasks instead of allocating new tasks, and task may have initial operation and state). In a sense we may want parametrized tasks. There are several ways of doing this in Ada: using generic packages (but this is a bit restrctive), or using another tagged type hierarchy, and have tasks parametrized (using an access discr. for example) with a specific type defining their behaviour. Other more technical design issues exist. A major issue is copying tasks (tasks are limited, so one must use access values), and GC them (Controlledness maybe problematic with all the inheritance going around, we don't have MI). We must also remember that tasks are by their very nature mutable: a task has state. This makes aliasing very problematic, and thus copying tasks is essential, yet difficult (recall that the tasks themselves are "limited"). How do we solve this prolem? If you answer is to use task allocator abstracion, You should reread this message... :-) All this makes this an interesting problem. I'd love to hear experiences people had with building such a thing (esp. in Ada95, since it offers what seem to me to be useful tools). My attempts are in rather more restricted domain; when finished I'll put them up somewhere. Ehud Lamm