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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,92a027c293f03acb X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!univ-lyon1.fr!news.uni-stuttgart.de!news.nask.pl!news.nask.org.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mail From: Wiktor Moskwa Newsgroups: comp.lang.ada Subject: Re: Workqueues in Ada Date: Sat, 28 Jul 2007 21:19:10 +0000 (UTC) Organization: tp.internet - http://www.tpi.pl/ Message-ID: References: <4rvzewqs9ba3$.pluy1xzoi5lr$.dlg@40tude.net> <16fd0klj7ul1d$.oi8lp7eybgxo$.dlg@40tude.net> NNTP-Posting-Host: aaeu42.neoplus.adsl.tpnet.pl X-Trace: nemesis.news.tpi.pl 1185657550 20870 83.4.124.42 (28 Jul 2007 21:19:10 GMT) X-Complaints-To: usenet@tpi.pl NNTP-Posting-Date: Sat, 28 Jul 2007 21:19:10 +0000 (UTC) User-Agent: slrn/0.9.8.1 (Linux) Xref: g2news2.google.com comp.lang.ada:1249 Date: 2007-07-28T21:19:10+00:00 List-Id: On 28.07.2007, Dmitry A. Kazakov wrote: > Why? What I don't understand is why removing from a queue should deallocate > anything. It might be an artefact of Ada.Containers, but in general case it > is not unnecessary. Removing just means that it is the task who will hold > the item. Technically the item will be either in no list or in the list of > one item long owned by the task. You have one list of items waiting for > service and n lists of items being serviced, where n = number of worker > tasks. Interlocking is only necessary when you move an item from list to > list. In GNAT GPL 2007 implementation of Doubly_Linked_Lists an Element is kept in a limited record called Node. When Append is called, new Node is created and when Delete - Free(Node) is called. Everything happens in a default storage pool and is transpated to malloc and free. Could you elaborate the concept of having an additional list of items per task? When it can be useful? I'm interested. > If you do this you would not need any lists, just a ring buffer of items. That's the name I was looking for :) > With a relatively small number of worker tasks the overhead of skipping > items in use is not that big, but you will have another potential problem: > unbalanced servicing. When an item was serviced a bit longer than its > neighbours, it might miss its train of servicing. What is worse it could > become a systematic problem for some items with a huge impact in result. I agree, I haven't consider balancing yet. > Doubly-linked lists do not have this problem, while removing and inserting > overhead is just negligible. You can shuffle items between lists very > efficiently. If you could write more about using more lists... thanks! -- Wiktor Moskwa